search

KantaraInitiative / wg-uma

This is the repository of all specifications related to the User Managed Access Group
http://kantarainitiative.org/confluence/display/uma/
Other
27 stars 21 forks source link

Should our token introspection object permissions structure be a MUST now? #322

Closed xmlgrrl closed 7 years ago

xmlgrrl commented 7 years ago

In FedAuthz Sec 5.1.1, @jricher suggests:

"why is "permissions" not a MUST? if it's an UMA token it'll have it, if it's not, it won't. the hand-wave to an extension feels weird here. an extension could just as easily say "our kind of tokens don't use that object" and so responses won't conform to the base spec but to the extension instead. just like a plain oauth token instead of an uma token."

The specific language in question:

"If the introspection object's active parameter has a Boolean value of true, then the object MUST NOT contain a scope parameter, and SHOULD contain an extension parameter named permissions that contains an array of objects, each one (representing a single permission) containing these parameters:"

xmlgrrl commented 7 years ago

Per UMA telecon 2017-05-18: We made a strong decision to make permissions be a SHOULD for extensibility reasons, in case someone wanted to experiment with the dividing line between AS and RS responsibilities. However, token introspection is already optional in OAuth, and with the spec refactoring, maybe this isn't necessary anymore. And changing from a SHOULD to a MUST is backwards incompatible, whereas the reverse isn't (it would break implementations to change it in this direction). Consensus to change to a MUST.