Re: [IPP] RFC: "oauth-authorization-scope (1setOf name(MAX))" Printer Description attribute

[Michael Sweet via ipp <[e-mail]>]

[Apologies for the delay in posting a follow-up after the last IPP WG concall...]

All,

The IPP workgroup reviewed this registration during the May 23, 2019 conference call. The consensus was to register this new attribute as-is.  The following is a summary of the discussions during the concall and via email:

- Q: Don't OAuth scopes control access to specific functionality and not access to a
     specific service?
  A: Yes, and that is what is proposed here, for example the generic End User printing
     functionality could have the scope name "printing", while Operator functionality
     has the scope name "print-operator", etc.

- Q: How does this work with Get-User-Printer-Attributes?
  A: Complicated, OAuth provides access authorization but does not necessarily
     provide identity information that could be used to lookup policy - might
     need to default to a generic/guest policy
     (also see the answer to the previous question - the scope might map to the
      granted policy)

- Q: How does a Printer get registered with an Authorization Server to do
     introspection?
  A: Currently that is an implementation detail - there is no Resource Server
     registration method defined for OAuth 2.0 (yet).


> On May 21, 2019, at 8:53 AM, Michael Sweet via ipp <[e-mail]> wrote:
> 
> All,
> 
> During some side discussions regarding OAuth 2.0, I realized that we currently have no way for a Printer to tell a Client which OAuth scope(s) to request for printing - currently a Client would just request the default list which sometimes means all scopes and sometimes a restrictive scope that doesn't convey any rights. Scopes can be thought of as a rough equivalent of user groups and are used to specify access roles or convey specific access rights, so if an Authorization Server is used to control 
> access to many different services (and not just to a printing service, as is the case for most federated OpenID services) we want to be able to ask for the right scope(s).
> 
> The following is my proposed solution...
> 
> 
> oauth-authorization-scope (1setOf name(MAX))
> 
> The "oauth-authorization-scope" Printer Description attribute provides an
> ordered list of OAuth 2.0 scopes that SHOULD be used in an authorization
> request.  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.  Clients
> SHOULD provide the full list of scopes in the initial authorization request and
> only prune the list if the OAuth 2.0 Authorization Server returns the
> "invalid_scope" error.
> 
> 
> Registration template:
> 
> Printer Description attributes:                 Reference
> ------------------------------                  ---------
> oauth-authorization-scope (1setOf name(MAX))    [IPP20190521]
> 
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer
> 
> _______________________________________________
> ipp mailing list
> [e-mail]
> https://www.pwg.org/mailman/listinfo/ipp

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

_______________________________________________
ipp mailing list
[e-mail]
https://www.pwg.org/mailman/listinfo/ipp