SURFnet / surf-token-based-access

1 stars 1 forks source link

GNAP-RS vs UMA-Fed-Auth #48

Closed michielbdejong closed 2 weeks ago

michielbdejong commented 2 months ago

Look into https://datatracker.ietf.org/doc/draft-ietf-gnap-resource-servers/

michielbdejong commented 2 months ago

GNAP-RS introspection response has:

access (array of strings/objects): REQUIRED. The access rights associated with this access token. This MUST be in the format described in the Section 8 of [GNAP]. This array MAY be filtered or otherwise limited for consumption by the identified RS, including being an empty array, indicating that the token has no explicit access rights that can be disclosed to the RS.

How does this compare with permissions in UMA-extended introspection responses?

Should we use GNAP-RS introspection responses instead of UMA-extended onese?

michielbdejong commented 2 months ago

Not only for the introspection response but also for the resource registration, GNAP-RS and UMA-Fed-Auth seem to present distinct options to solve a similar problem: In UMA-Fed-Auth the RS defines a name and list of scopes and the AS adds the ID.

In GNAP-RS 3.4. Registering a Resource Set", the RS posts an array of RARs (where RAR stands for Resource Access Rights, NOT Rich Authorization Requests!)

michielbdejong commented 2 months ago

https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-protocol#section-8 defines:

michielbdejong commented 2 months ago

The choice between UMA Resource Registry and GNAP-RS Resource Set Registry feels like a syntactical detail, unless I misunderstood some profound difference between them.

We will need to make a choice but will follow common practice from the OAuth community here.