Hi Michael and Smith,
Regarding the implementation of the client, I would keep two caches:
1. access tokens for printers indexed by "printer-uri" (or for IPP Systems
indexed by "server-uri")
2. access tokens for Authorization Servers indexed by
"oauth-authorization-server-uri" and "oauth-scope"
When the client communicates with a printer the cache 1 is used (when the
printer requires OAuth). If the printer is missing there or the current
access token is rejected the client queries
"oauth-authorization-server-uri" and "oauth-scope" from the printer and
tries to match an entry in the cache 2. If the entry is found the client
does TokenExchange (in the background) to get the new access token for the
printer (and saves the new access token in the cache 1). If there is no
matching entry in the cache 2, the client must go through the authorization
procedure to get an access token for the authorization server and given
scope ("oauth-authorization-server-uri" and "oauth-scope"). The
authorization procedure here means standard Authorization Code flow with
PKCE (opening the internet browser, letting the user to authenticate etc).
Both these caches are kept in the context of the current OS user session
(they are wiped out when the user closes the session).
As Michael mentioned, the client cannot make any assumptions about
equivalency of access tokens. Each of them may be different or many of them
may be identical. Because of that, they cannot be used as an index or
unique key. Or even assume that they are unique for a given client.
Thanks,
Piotr
On Mon, Oct 17, 2022 at 11:36 AM Michael Sweet via ipp <ipp at pwg.org> wrote:
> Smith,
>> > On Oct 14, 2022, at 3:41 PM, Kennedy, Smith (Wireless & IPP Standards) <
>smith.kennedy at hp.com> wrote:
> >> ...
> >> If I am reading this right it looks like they are saying we should
> treat different hostnames as different OAuth "realms", which seems to be an
> obvious answer. I would go slightly farther and say the combination of
> "oauth-authorization-server-uri" and "oauth-scope" should be used when
> caching authorization tokens for a given realm, and
> "oauth-authorization-server-uri", "oauth-scope", and "printer-uri" (or
> "server-uri") for access tokens (since token exchange yields
> device/service-specific tokens).
> >
> > I agree these seem like some of the elements / attributes one of these
> profiles might contain.
> >
> > If there is consensus on this in principle (we can work out the details
> if there are other elements / attributes that should be present instead or
> in addition to the ones above), I think there are two other questions that
> we need to address in our update to 5199.10 and friends:
> >
> > a) Is there a need for UI to allow the user to select one of these
> profiles? Or is there even a possibility of ambiguity?
>> If we accept the metadata provided by the OAuth server, then the Client is
> able to determine whether token exchange is in use. But that is just an
> optimization - we can choose to always only cache for the specific
> oauth-authorization-server-uri/oauth-scope/printer-uri tuple. When token
> exchange isn't in use then you'll get the same access token for each
> printer-uri, otherwise each token will be unique.
>> > b) the general assumption is that these profiles are local to the
> client. I have to assume these tokens aren't transferrable between clients?
>> You can't make that assumption. OAuth doesn't specify whether access
> tokens are tied to a particular Client/address. If you possess a valid
> token, you can access the resource. If you have a refresh token or other
> needed information, you can get a new access token and continue accessing
> the resource after the original access token expires or is revoked.
>> Many OAuth-based services also offer "API keys" (persistent access
> tokens), which can likewise be used from any Client until they are revoked.
>> > If they are transferrable, and could be pulled in from a cloud account /
> interface, does OAuth 2.0 or OIDC define an endpoint that can be used to
> provide these? If not then that is veering into proprietary uniqueness and
> is outside the scope of our work, because I don't think the PWG wants to
> get into the business of defining additional OAuth 2.0 endpoints.
>> I think we want to focus on pointing implementors to the current OAuth
> best practices.
>> ________________________
> Michael Sweet
>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20221017/048ec125/attachment.html>