Smith,
> On May 7, 2018, at 12:12 PM, Kennedy, Smith (Wireless & Standards Architec) <smith.kennedy at hp.com> wrote:
>> Greetings again,
>> Following some discussions within HP, I had a couple of points of feedback that I hope we can discuss in the review of this draft.
>> 1. With OAuth2, how can the Printer know the identity of the "most authenticated user" when the authentication is handled by the Authorization Server, not the Printer? In section 3.1.6 of the draft announced below, perhaps some additional provisions or considerations are needed to complete the definition of how OAuth2 can be a viable authentication mechanism for IPP, because if "Get-User-Printer-Attributes" and OAuth2 were to be used together, the Printer could need to be aware of the user's identity.
So for the purposes of IPP, the "most authenticated user" is the user that is authenticated via HTTP (the user info you get from introspecting the bearer token). The order is (from most to least):
1. HTTP Authenticate information (most authenticated)
2. TLS client certificate information, if any (often only authenticates the Client, not the User)
3. requesting-user-name (least authenticated)
> 2. AFAIK IPP or its use of HTTP has no notion of a "session token" (stored in a cookie, etc.) for providing proof of previous authentication in subsequent operation requests. If that is so, then how is the authentication handled with subsequent IPP operations?
By the client sending the authentication info in each request. If the client doesn't send the auth data it gets a 401 challenge.
> For instance, if there is a sequence of Validate-Job / Create-Job / Send-Document / Get-Printer-Attributes / Get-Job-Attributes, does the Printer re-challenge the Client each time? Or is there a "session token" that can eliminate those steps for subsequent connections? If the Client has to cache the "username / password" provided by the User for the subsequent operations, what guidance should this white paper provide?
Basically, once a particular "origin" has challenged the Client, the Client is expected to re-send the auth data in every subsequent request to that origin. If not, the Printer has to do the 401 challenge dance. Similarly, some auth schemes (like Digest) will only allow a certain number of reuses before the challenge is issued again.
CUPS' http_t object caches both the username/password and Authentication header value (for Negotiate, Bearer, etc.), so usually you just have to supply credentials once per print job.
_________________________________________________________
Michael Sweet, Senior Printing System Engineer