Michael and Paul, thanks very much for your helpful replies!
*Jeremy Leber*
Area Owner, Network Firmware Development
*O* +1 859 825-4505
jeremy.leber at lexmark.com
<http://www.lexmark.com/>
www.lexmark.com
On Wed, Nov 16, 2016 at 2:52 PM, Michael Sweet <msweet at apple.com> wrote:
> 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/77826100/attachment.html>