> On Apr 19, 2017, at 7:05 AM, Michael Sweet <msweet at apple.com> 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) <smith.kennedy at hp.com> wrote:
>>>> 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>>>> 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
>>ipp at pwg.org>>https://www.pwg.org/mailman/listinfo/ipp>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer
>
-------------- 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/20170420/3b076b48/attachment.p7s>