> On Jul 24, 2017, at 2:33 PM, Michael Sweet <msweet at apple.com> wrote:
>> Smith,
>> PWG 5100.18 is IPP INFRA... :)
>
Eeek - how did I make that mistake? :p
> The "oauth-authorization-server-uri" Printer Description attribute specifies the OAuth server that the printer uses (and thus the client must use to obtain a bearer token) - this is needed because RFC 6750's WWW-Authenticate header does not include the authorization server...
>> OAuth Bearer tokens (used for HTTP authentication) do NOT rely on redirection, but instead use a cached token string that the Client obtains by going to the auth server. Think Github API tokens...
>> The "access-oauth-token" member attribute contains the bearer token for the specified remote resource, and is how you provide third-party access to a resource. The "access-oauth-uri" points to the OAuth server used. The Printer uses the "access-oauth-token" value in the HTTP Authentication field, e.g.:
>> Authentication: Bearer dflkjfler232rsdlfkj45efdlk12fasf
I'm clearly not an OAuth2 expert, but the diagram I have in my "IPP Authentication" deck, with an HTTP 302 Found redirection seems to be describing a different use of OAuth2 authentication than what is outlined in RFC 6750 - is that a fair statement? IPP INFRA didn't mention RFC 6750 so the distinction is not clear. And are you saying that an OAuth2 "Access Token" is NOT a supported authentication mechanism for IPP? (Am I reading this right?) Is this because you are trying to control access on a per-resource basis?
Do we need additional keywords for "uri-authentication-supported" to make it clear that 'oauth' refers to OAuth2 Bearer authentication [RFC6750]? (What about kerberos?)
>>>> On Jul 24, 2017, at 2:37 PM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com> wrote:
>>>> Greetings,
>>>> I am working on converting the "IPP Authentication" slide set to a whitepaper. In the process, I've been considering OAuth a bit more. PWG 5100.18 (IPP Transaction Based Printer Extensions) defines the "oauth-authorization-server-uri", "access-oauth-token", and "access-oauth-uri" attributes. It isn't clear to me how these attributes integrate into an OAuth authentication system.
>>>> The way that OAuth / OAuth2 seems to work, there will be an HTTP response redirecting the User Agent (IPP Client) to a different server for authentication. If this is all handled at the HTTP layer, what value do these IPP attributes provide?
>>>> Thanks for any help,
>>>> 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/20170725/befd88e2/attachment.p7s>