Hi Mike,
I envisioned one of the outputs of a XACML procedure to be an authorization token that is securely attached/associated/derived-from a particular request.
Having a XACML predicate that derives its' output from some external payment/accounting system would allow a "paid" transaction -- what I was trying to avoid was having two different definitions of what it means for an imaging job to be "authorized" -- if our overall authorization goals for imaging jobs could subsume the payment-requirement, then we could coalesce the authorization space, and define any and all abstractions as a part of the authorization scope for imaging.
It's just a "goal" that I've had in mind to have any and all authorization requirements (user-capability, payments, security, etc.) under a common "authorization umbrella" that does in fact do what you allude to in your proposal, and that means return an authorization token, ideally secured and attached/associated with a particular imaging job request (tied back to the parameters of the job ticket).
I'm still digesting/processing the proposal and its' implications so I may have something more concrete to say about this at a future tel-conference or possibly in Cupertino. That being said, it's good to see that some of the operational aspects (authorization URI or "token" of some sort) of the "authorization problem" have been exposed, which is part of what I have been looking at with an overall authorization service.
R.
On Mar 26, 2013, at 9:05 AM, Michael Sweet <msweet at apple.com> wrote:
> Randy,
>> On 2013-03-25, at 11:51 PM, Randy Turner <rturner at amalfisystems.com> wrote:
>>>> After taking a quick look at the *initial* IPP Paid Printing Extensions proposal, I think a dedicated URI name space for anything *paid* related is a good idea, and I would probably link this namespace to the work we need to do on XACML authorization.
>> For the purposes of this specification I am just interested in conveying the authorization as a URI so that implementations can choose the namespace that makes the most sense for them. If we can separately define a namespace that is "ideal" for transaction-based imaging, all the better.
>>> Seems like *payment* might just be another coefficient in an equation that calculates the overall *authorization disposition* for a user trying to use a resource
>> -- I meant to join the call today (Mon, 3/25), but had a last minute commitment I had to deal with. I will try and send additional thoughts/comments soon.
>> Thanks!
>> FWIW, the spec is titled "paid printing" but it really just defines a generic transaction-based printing mechanism. The "payment" portion is abstracted out - all we care about is enabling printing transactions so that a payment system can actually be implemented: have the necessary metrics, be able to associate a job with a transaction (job-authorization-uri), and have the status/reporting infrastructure in place so that a Client can react accordingly to issues associated with the transaction. Certainly a paid Printer's access policy will be driven by the authorization URI, whether defined using XACML or some other method...
>>>>> R.
>>>> On Mar 25, 2013, at 4:36 PM, Michael Sweet wrote:
>>>>> All,
>>>>>> I have posted the minutes to today's IPP conference call to:
>>>>>>ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20130325.pdf>>>>>> Our next conference call is April 8, 2013 at 3pm ET.
>>>>>> _________________________________________________________
>>> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>>>>>>>> --
>>> This message has been scanned for viruses and
>>> dangerous content by MailScanner, and is
>>> believed to be clean.
>>>>>> _______________________________________________
>>> ipp mailing list
>>>ipp at pwg.org>>>https://www.pwg.org/mailman/listinfo/ipp>>>>>>>>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>>> _______________________________________________
>> ipp mailing list
>>ipp at pwg.org>>https://www.pwg.org/mailman/listinfo/ipp>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.