Hi Piotr,
> On Oct 27, 2022, at 12:11 PM, Piotr Pawliczek <pawliczek at google.com> wrote:
>> CAUTION: External Email
> Hi Smith,
>> Sorry for the late answer. I had to scroll through the OAuth specs to refresh my memory.
>> On Tue, Oct 25, 2022 at 3:36 PM Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com <mailto:smith.kennedy at hp.com>> wrote:
> ....
>> Yes, that is part of it. If a printer I discover using my phone at work supplies "uri-authorization-server-uri" = 'authz.x.io <http://authz.x.io>', and so does my printer at home, and the Client in the phone already holds access tokens for both, does the Client in my phone try token exchange with each account it holds an auth token for? If an identifier for the printer were provided in steps 3 and/or 4, (step 3 being unnecessary if already authenticated), then the authz could know the "context" / "domain".
>>> What do you mean by "the phone already holds access tokens for both"? Do you mean that you have two sessions with 'authz.x.io <http://authz.x.io>' with different scopes?
Yes.
> In this case, the client should try any current session with AS that includes scopes provided by the printer.
> OAuth does not allow you to send printer-uri (resource-url) in steps 3 or 4. The only way to do this is to force the client to use printer-uri as a scope (or maybe merge with the scopes queried from the printer?). But in this case you have to log into each printer separately.
Bummer. This makes SSO difficult (impossible?).
>> This gets awkward when you get into a SSO situation in an enterprise if the authz isn't unique for that context. If a user selects a different printer at work than one they have used before, they will be forced to re-authenticate since the Client has no way of knowing whether that printer is a member of a context associated with one of the already-logged-in accounts or some different account. So it seems like the "scope" of the context identifier may be a single printer (highly granular access control) or a collection of printers (SSO in an enterprise). That makes me think neither the printer UUID nor a particular X.509 certificate satisfies the scope needs for this "context identifier" unless the identifier comes from further up the certificate chain or something...
>>> I am a little bit lost here. :)
>> When the scopes of the existing AS session does not include the scopes provided by the printer, a new session with AS must be opened (the user must go again through the authorization procedure with new scopes).
> More complicated situation occurs when the user has two accounts on the AS and logs into the wrong one. In this case, the user would have to log out and log in again. But (I think that) this kind of problem exists for all OAuth implementations. The scopes must yield enough info to make sure that the user's account has rights to use the printer (printer-uri is not known by the AS at that time). Then the problem with different accounts disappears.
>> According to my understanding of OAuth 2 philosophy, the authorization procedure (all webpages shown to the user by AS etc) is the process where the IPP Client asks the user for access to given scopes. And this is what the AS codes in the issued access token when the user gives the permission(=completes the authorization procedure). The fact, that the user must go through some authentication process (login/password or something else) is a kind of side effect of the procedure. The user identity is not used outside the authorization procedure.
>> I think that "the context" you referred to must be coded in scopes queried from the printer. I also think that we have to define how the "oauth-scopes" are used, in other case there is going to be a huge mess.
>> printer-uri and pinning X.509 certificate (and TokenExchange request in general) is used for verification of the printer's identity. It is not related to access rights. Access rights to the printer must be guaranteed by the scopes.
OK I need to think on this a bit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20221027/ef414fb2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://www.pwg.org/pipermail/ipp/attachments/20221027/ef414fb2/attachment.sig>