> On Nov 14, 2017, at 11:44 PM, Kennedy, Smith (Wireless & Standards Architec) <smith.kennedy at hp.com> wrote:
>> 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?
Technically yes, however the current best practice is to run the authentication page either in the default web browser or an isolated web view so that the application does not have access to state/cookies/etc. that it shouldn't have access to and it isn't as easy to spoof the OAuth authorization form.
> Also, if IPP is performed before Step 1, then is the "Step 0" a IPP Get-Printer-Attributes or Validate-Job IPP operation?
You need to do a Get-Printer-Attributes request to get the OAuth Authorization Server URL ("oauth-authorization-server-uri") to use in step 1... You might have done other IPP requests the triggered the 401 response with the Bearer scheme challenge, or you might have gotten the authentication info when presenting the print UI and then proactively done the authentication step.
>> 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?
(and as for using "ipp" as the scheme, that is totally OK but just needs to be registered with the client ID when you setup the OAuth environment...)
>> 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"?
Yeah, you could look at it that way. The second step basically is a way of confirming that you did the first step and got the redirect - kind of like getting a credit card and then calling to activate it.
>> 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?
The access token must be protected just like a password. And that's why the "destination-accesses" and "document-access" collections are operation attributes - they are not externally visible in the Job object because they contain sensitive information that is not supposed to be exposed.
Michael Sweet, Senior Printing System Engineer