Subject: [IPP] Documenting IPP uses of HTTP authentication mechanisms (Basic / Digest / OAuth2)

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Wed, 19 Apr 2017 04:17:43 +0000

Hello,

Recently, when reviewing the "Get-User-Printer-Attributes" white paper internally, I got asked a bunch of questions about how IPP works with different HTTP authentication / authorization models. I don't have a deep knowledge of this space, but I thought it was something that was important to document. I created sequence diagrams for a number of different HTTP authentication / authorization schemes and how I imagined IPP would fit into this. I have uploaded a PDF with these sequence diagrams for review by the IPP WG:

http://ftp.pwg.org/pub/pwg/ipp/whitepaper/ipp-authentication.pdf <http://ftp.pwg.org/pub/pwg/ipp/whitepaper/ipp-authentication.pdf> 

Any feedback? Should we perhaps make a new white paper / technical brief that incorporates approved versions of these to document this increasingly important aspect of IPP Client / Printer interaction? In particular I don't know if I got the OAuth2 portion correct.

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 mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Thu, 20 Apr 2017 15:48:22 +0000

> On Apr 19, 2017, at 7:05 AM, Michael Sweet <[email-masked]> wrote:
> 
> Smith,
> 
> As IPP uses HTTP POST, the sequence diagram for any HTTP auth scheme is the same as for a typical web form submission.  Aside from providing a visual for IPP implementers with no HTTP experience, I'm not sure whether this is necessary or useful since it could be interpreted as "IPP is different" (when it isn't...)

I know, and I 100% agree with your concern that if we document something that documentation's existence makes it seem like IPP is more unique than it actually is at that level. I think the primary issue isn't the protocol itself but the client's local response to the different challenge types. And part of the problem space concerns the nature of the HTTP client being or not being a conventional web browser.

If I am understanding what I'm observing correctly, when a browser receives an HTTP 401 with WWW-Authenticate, it will generally show some type of authentication dialog, corresponding to the authentication type (e.g. Basic and Digest may trigger presentation of a dialog with username and password text fields; certificate may present a certificate selection list).

I have next to no experience with OAuth2, so I need some help with this. But looking at sequence diagrams that I cribbed for my own diagrams,   OAuth2 appears to have built into it an assumption that the client will allow presentation of HTML / web content in an HTML rendering window control. 

The reason why I think this is significant is that, whether the client is a browser or some other type of application, handling a 401 can and usually is handled via a dialog constructed from nearly 100% local UI resources. In contrast, OAuth2 seems to require that the client have some capacity to render HTML or other web content in order to present the UI. So if OAuth2 were used for IPP, either the clients themselves would need to implement support for rendering web content somehow, or the OAuth2 system would need to recognize that the user agent isn't a web browser, and change what they send to the client, or something similar.

Is OAuth2 used in managed print systems for authentication today?

> 
> I could see these as part of an informative appendix to an updated implementor's guide, once any error are eliminated...

I think that would be fine. I can file an errata request against 5100.19 for that.

> 
> 
>> On Apr 19, 2017, at 12:17 AM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:
>> 
>> Hello,
>> 
>> http://ftp.pwg.org/pub/pwg/ipp/whitepaper/ipp-authentication.pdf 
>> 
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer
>

---

From: Michael Sweet <[email-masked]>
Date: Fri, 21 Apr 2017 08:06:26 -0400

Smith,

> On Apr 20, 2017, at 11:48 AM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:
> ...

Correct; the actual UI varies widely which is one of the reasons why most web sites do not use HTTP authentication...

> I have next to no experience with OAuth2, so I need some help with this. But looking at sequence diagrams that I cribbed for my own diagrams,   OAuth2 appears to have built into it an assumption th…

Not exactly.  There are a few required interfaces that need to be implemented by an OAuth2 server, one of which is a required GET endpoint that accepts a set of standard query parameters (what would be provided in a form) that can be used by a non-browser client ("native application" in their terminology) to enable the kinds of behavior we'd want/need for a printing client.  And this (non-idempotent...) GET request can be additionally authenticated using HTTP Basic to authenticate the client (...).

The bigger issue is that OAuth as a HTTP authentication scheme is poorly defined; the Bearer scheme (RFC 6750) does not include any parameters in the WWW-Authenticate header to point clients to the OAuth server to use, which is why we have a separate IPP attribute (accessible via Get-Printer-Attributes...) to tell the client which server endpoint to use...  The common usage for *that* method can be see in things like Github, where you get a multi-use access token from the Github web site and then use that as proof you are who you say you are...

TL;DR: OAuth is required to work without browsers.  And we have defined what is needed to implement IPP printers and clients that use it.  But actual implementation could probably use some documentation since there is obviously some confusion...

> ...

I'm not aware of any large-scale deployments, but it is certainly possible there are proprietary systems doing so.