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> 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', 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' with different
scopes? 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.
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.
Let me know if I lost you on that one. 😊
>> ...
>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20221027/5af1b1fe/attachment.html>