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