Comparison with PAT / Fed Auth for UMA

[michielbdejong]

See https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-federated-authz-2.0.html Seems to have some interesting overlap with our work.

The resource server defines the boundaries of resources and the scopes available to each resource, and interprets how clients' resource requests map to permission requests, by virtue of being the publisher of the API being protected and using the protection API to communicate to the authorization server.

Reading it now to work out how it can fit together

[michielbdejong]

The protection API works in the opposite direction (RS accesses it at AS instead of AS accessing it at RH-API) but otherwise it's really quite similar. It allows for defining resources and then scopes for those resources.

We should probably not be proposing our scope info data structure independently if UMA 2.0 scope description already exists. Maybe adopt and extend where necessary?

I don't remember if we had a particular reason to say the scope definition lives in the RH and is later retrieved by the AS. Especially since our 4 April edits of the swimlanes, where we decided that the AS should cache the RH-API response, it might make sense if we align on this and let the RH posts the scope info to the AS instead!

[michielbdejong]

One question I have is if we can specify data for introspect and for client config through this resource registry, and if not, if that's OK or if we then still want to have that as features.

The authorization server MAY support both UMA-extended and non-UMA introspection requests and responses.

Ah right, in an UMA-extended token introspection endpoint,

If the introspection object's active parameter has a Boolean value of true, then the object MUST NOT contain a scope parameter, and MUST contain an extension parameter named permissions that contains an array of objects, each one (representing a single permission) containing [at least resource_id and resource_scopes]

Perfect! And UMA doesn't need client config discovery because it starts at the RS API request and then has AS discovery instead...

[michielbdejong]

I'll draft an alternative version of our spec in the light of this, called "OAuth Resource Helper" instead of "OAuth Scope Info"

https://docs.google.com/document/d/17js_fmroZJsBj1z7IPG-RzNnyYjjGNJju-tXTsfEtHo/edit

[michielbdejong]

Comparison complete, with the poc-3 folder and the OAuth Resource Helper spec draft. I will leave it to @pmeulen to choose which one we present at OSW tomorrow