[IPP] Assistance in correcting the "OAuth2" diagram in IPP Authentication?

[IPP] Assistance in correcting the "OAuth2" diagram in IPP Authentication?

[IPP] Assistance in correcting the "OAuth2" diagram in IPP Authentication?

Kennedy, Smith (Wireless & Standards Architec) smith.kennedy at hp.com
Wed Nov 15 04:44:39 UTC 2017


Hi Mike,

I'm not sure how to incorporate your feedback into the current OAuth2 sequence diagram. I will list some of my questions here, but we may need to save discussion till the F2F session.

> 1. Web-based authentication/authorization - a web browser has to be used, out-of-band from IPP, to obtain a "grant" from the Authorization Server.

Could that not be implemented such that the client provides its own "web view" able to render web content as per the current OAuth2 sequence diagram?

Also, if IPP is performed before Step 1, then is the "Step 0" a IPP Get-Printer-Attributes or Validate-Job IPP operation?

>  The grant is supplied via a URL redirect that is primarily geared towards web services (point to a HTTPS web page on service X) but can also use application-specific URL schemes ("myspecialapp://bla/?code=fsdlfkjasdfdsfsd0324df"), which is how you implement OAuth2 for so-called "native apps".

OK so the HTTP response will be an HTTP 302 or similar, where the URL could be an https scheme, or could be some other scheme? What about the "ipp" scheme? Or maybe that is too premature / inappro. But the token comes in as basically a parameter in the URL in the 30x redirect response?

> 
> 2. Once you have the grant, you can request an "access token" (and optionally a "refresh token", which is essentially a grant you can use at a later time to keep using the resource) from the authorization server using a HTTP POST (no web browser needed).

So the "grant" is basically an "access token access token" that allows the Client to request an "access token"?

> 
> 3. Once you have the access token, you can supply it in response to the HTTP 401 status code with a "WWW-Authenticate: Bearer" header.

And it is up to the Client to manage that access token? Is it typically stored in a cookie or via some other place / method?

Smith

/**
    Smith Kennedy
    Wireless & Standards Architect - IPG-PPS
    Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB-IF
    Chair, IEEE ISTO Printer Working Group
    HP Inc.
*/



> On Nov 10, 2017, at 10:53 AM, Michael Sweet <msweet at apple.com> wrote:
> 
> Smith,
> 
> OK, so to "help" I think we need to separate things because OAuth2 has three distinct steps:
> 
> 1. Web-based authentication/authorization - a web browser has to be used, out-of-band from IPP, to obtain a "grant" from the Authorization Server.  The grant is supplied via a URL redirect that is primarily geared towards web services (point to a HTTPS web page on service X) but can also use application-specific URL schemes ("myspecialapp://bla/?code=fsdlfkjasdfdsfsd0324df <myspecialapp://bla/?code=fsdlfkjasdfdsfsd0324df>"), which is how you implement OAuth2 for so-called "native apps".
> 
> 2. Once you have the grant, you can request an "access token" (and optionally a "refresh token", which is essentially a grant you can use at a later time to keep using the resource) from the authorization server using a HTTP POST (no web browser needed).
> 
> 3. Once you have the access token, you can supply it in response to the HTTP 401 status code with a "WWW-Authenticate: Bearer" header.
> 
> Only step 1 requires a web browser.
> 
> Only step 3 is in-band of IPP.
> 
> The token you get in steps 1 and 2 can potentially be reused indefinitely.  When you get a 401 with and error parameter in the WWW-Authenticate header, it is time to either a) refresh the access token or b) repeat steps 1 and 2 to re-authenticate.
> 
> The list of RFCs is extensive (https://oauth.net/2/ <https://oauth.net/2/>) but the important ones for IPP are:
> 
> - RFC 6749: The OAuth 2.0 Authorization Framework (doing out-of-band authentication and getting access tokens)
> - RFC 6750: OAuth 2.0 Bearer Token Usage (doing in-band authentication)
> - RFC 7636: Proof Key for Code Exchange (doing out-of-band authentication more securely with native Client applications)
> - RFC 8252: Recommendations for using OAuth 2.0 with native apps (doing out-of-band authentication on a Client - for implementors)
> 
> The following Internet Draft will (hopefully) define how an input constrained device like a printer can authenticate as a client (important for IPP INFRA proxies).
> 
> 
>> On Oct 25, 2017, at 3:59 PM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com <mailto:smith.kennedy at hp.com>> wrote:
>> 
>> Hi Mike,
>> 
>> One of my action items to move the IPP Authentication white paper forward was to solicit help from you in correcting the OAuth2 diagram(s). Could you take a look at the attached PlantUML sequence diagram files and make corrections you feel are needed? The versions from the latest white paper (from August) are attached - there are two of them. You can edit it in any text editor, then render it using the PlantUML tool:
>> 
>> http://plantuml.com/download <http://plantuml.com/download>
>> 
>> Thanks in advance! 
>> 
>> Smith
>> 
>> /**
>>    Smith Kennedy
>>    Wireless Architect - Client Software - IPG-PPS
>>    Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB IF
>>    Chair, IEEE ISTO Printer Working Group
>>    HP Inc.
>> */
>> 
>> 
>> <ipp-authentication-6-http-oauth2.pu><ipp-authentication-8-http-oauth2-with-digest.pu>
> 
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20171115/0f21fb2e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4241 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20171115/0f21fb2e/attachment.p7s>


More information about the ipp mailing list