Smith,
> On Aug 29, 2025, at 10:30 AM, Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com> wrote:
>> Hi Mike,
>> HP had 2 points of feedback:
>> * Section 4.3 "Scoped Access Tokens" describes how either scopes or token exchange can be used to limit scope. What isn't clear is how a client will know when one or the other are being used?
Scopes are always used (required part of OAuth), and section 4.3 references the REQUIRED "oauth-authorization-scope" Printer/System Description attribute (section 5.1.1) containing the required value(s).
WRT token exchange, that depends on the presence of the "urn:ietf:params:oauth:grant-type:token-exchange" grant type in the "grant_types_supported" metadata. I'll add mention of this to section 7.3 where we talk about the authorization flows.
> The Client may not understand the hidden semantic meaning of the types of scopes.
That is a weakness of OAuth, but section 5.1.1 says:
This REQUIRED attribute provides an ordered list of OAuth 2.0 scopes that have been configured to be used in an authorization request for this Printer or System. If the attribute lists more than one scope name, the first name provides the least access, e.g., the "End User" role in IPP, while the last name provides the most access, e.g., the "Administrator" role in IPP. The scope name 'openid' has special meaning for OpenID Connect [OPENID].
Clients SHOULD provide the full list of scopes in the initial OAuth 2.0 authorization request and only prune the list if the Authorization Server returns the "invalid_scope" error.
TL;DR: Clients should just use what the Printer/System says they should use, and prune the latter values (ordered list from least to most access) if all of them fail.
> If Clients, Printers, Proxies and Systems MUST support scopes _and_ Token Exchange, do they need to know which one is being used by the authorization server?
For any of the OAuth implementations we care about, scopes are always used (even if it is just "openid" or "profile"). The metadata provided by the server tells you what the AS supports, and the "oauth-authorization-scope" Printer/System attribute tells you what scope(s) to use with that Printer/System.
> Are there requirements on the Authorization Servers? Is it impractical to just mandate
> Token Exchange for Clients, Printers, Proxies, Systems and Authorization Servers?
We made a choice at the beginning of this odyssey not to try to mandate anything to the OAuth/OpenID folks. Token Exchange is nice to have but I don't think it should be mandatory. It also isn't widely implemented...
> * Section 7.3 "Authorization Flows" mentions Device Authorization Grant. Can this be updated to either indicate how a DAG would be incorporated into a print related use case?
I believe this falls under the heading of "print or display a QR code". The DAG RFC talks about communicating a URL to the user with different methods, and the typical solution for IoT devices of all shapes and sizes is to display a QR code and/or URL with the access code, which you then open up in a browser (usually from your phone or tablet, but computer works too) to authorize against the AS.
Unless you have a large enough touch screen on your printer (where you could do a native client auth flow from the touch screen), and because of the widespread lack of dynamic client registration support, it is basically impossible for an "embedded" Printer/System/Proxy to do a traditional OAuth authorization flow via the web interface since you can't redirect back to the printer/system. This is why DAG exists...
________________________
Michael Sweet