Jeremy,
> On Nov 16, 2016, at 1:34 PM, Jeremy Leber <jeremy.leber at lexmark.com> wrote:
>> Hi All,
>> I could use some clarification on the proper way to use OAuth with IPP, given the following scenario:
>> I have an IPP endpoint that requires verification of the client's identify and validation of the client's authorization before printing a job. The client has obtained an OAuth token that will be used for this purpose.
>> When implementing this, should the implementor assume that IPP allows and expects OAuthv2 tokens to be included in the HTTP header (as would be the case for any other HTTP request)?
>Yes.
> If this IS the case, does the system expect any other user authentication information in the IPP request itself?
>Per RFC 2911, the "requesting-user-name" attribute (and/or the "requesting-user-uri" attribute from PWG 5100.13) can be supplied in a request, but the OAuth2 identity would be considered more authoritative.
> As an implementor, when implementing an IPP service with OAuth, are the following assumptions correct?
>> uri-authentication-supported MUST contain 'oauth' if OAuthv2 is supported
Yes
> oauth-authorization-server-uri MUST contain the OAuthv2 authorization URI to be used to authorize the user if uri-authentication-supported contains 'oauth'
Yes
> The users actual OAuthv2 token MUST be supplied in the HTTP Header Authorization line as a Bearer Token per the Oauth RFC
> The IPP service will/may authorize access to the printer/device using the supplied OAuthv2 token
Yes and yes.
> access-oauth-token and access-oauth-uri are only used to access a Document on behalf of the user to be processed by the service not for printer/device access itself
Correct.
> And a few extra questions:
> Has any discussion or consideration been had regarding using ID tokens to represent the job owner (i.e. the requesting-user-name)?
Some of the work in the IDS Model document included elements for this, and the IPP System Service specification adds a "job-owner-col" Job Status attribute that could be extended to include a member attribute, but right now an implementation just copies the name and ID (as a URI, so this could be an email address, etc.) to the "job-originating-user-name/uri" attributes.
> If the authentication process using SAML or OpenID Connect, it may retrieve a JWT or SAML Assertion which contains the user's identity, has any discussion been had about the benefits or pitfalls or delvierying the JWT/Assertions as the identity instead of a simple requesting-user-name?
We haven't discussed this specifically, however the "requesting-user-name/uri" attributes are considered non-authoritative - implementations are supposed to copy the most authoritative values.
_________________________________________________________
Michael Sweet, Senior Printing System Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20161116/1a4e8696/attachment.html>