Subject: [IPP] Questions regarding IPP and oAuth

From: Jeremy Leber <[email-masked]>
Date: Wed, 16 Nov 2016 13:34:49 -0500

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)?

If this IS the case, does the system expect any other user authentication
information in the IPP request itself?

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
   - oauth-authorization-server-uri MUST contain the OAuthv2 authorization
   URI to be used to authorize the user if uri-authentication-supported
   contains 'oauth'
   - 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
   - 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

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)?
   - 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?

Sorry for the lengthy questions... would love to get some quick feedback
from the group.

Thanks!
Jeremy

*Jeremy Leber*
Area Owner, Network Firmware Development

*O*  +1 859 825-4505
[email-masked]

<http://www.lexmark.com/>
www.lexmark.com
_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Paul Tykodi <[email-masked]>
Date: Wed, 16 Nov 2016 14:09:09 -0500

Hi Jeremy,

We had some OAuth - IPP discussions when creating the IPP Scan specification and I believe the approved IPP Scan standard may include answers to some of your OAuth security token related questions.

I'm currently out of the office in a location where I can't access the IPP Scan standard to check my memory on what we ultimately included about OAuth though.

Hopefully you might get a little help from the IPP Scan standard while waiting for others to respond.

Best Regards,

/Paul

Sent from my iPhone

> On Nov 16, 2016, at 1:34 PM, Jeremy Leber <[email-masked]> 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)?   
> 
> If this IS the case, does the system expect any other user authentication information in the IPP request itself?
> 
> 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
> oauth-authorization-server-uri MUST contain the OAuthv2 authorization URI to be used to authorize the user if uri-authentication-supported contains 'oauth'
> 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
> 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
> Has any discussion or consideration been had regarding using ID tokens to represent the job owner (i.e. the requesting-user-name)?
> 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?
> 
> Sorry for the lengthy questions... would love to get some quick feedback from the group.  
> 
> Thanks!
> Jeremy
> 
> Jeremy Leber
> O  +1 859 825-4505

---

From: Michael Sweet <[email-masked]>
Date: Wed, 16 Nov 2016 14:52:27 -0500

Jeremy,

> 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.

> 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 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.

> 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…
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

---

From: Jeremy Leber <[email-masked]>
Date: Wed, 16 Nov 2016 21:22:46 -0500

Michael and Paul, thanks very much for your helpful replies!

*Jeremy Leber*

*O*  +1 859 825-4505
[email-masked]

On Wed, Nov 16, 2016 at 2:52 PM, Michael Sweet <[email-masked]> wrote:

> 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.
>
>    - oauth-authorization-server-uri MUST contain the OAuthv2
>    authorization URI to be used to authorize the user if
>    uri-authentication-supported contains 'oauth'
>
> Yes
>
>
>    - 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.
>
>
> 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.
>