Please review the below comments, which include options and some proposals, and let me know your thoughts. I'll plan on publishing Core rev 08 by Wednesday of next week, incorporating any feedback I hear. ==== In today's call, we discussed Core rev 07 Sec 3.4 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-07.html#check-rpt-status> pretty heavily, and Sec 7.1.1 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-07.html#redirect-threats>'s last bullet a bit. Meeting notes are here <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-11-10>. Specifically: "Eve is concerned that not being able to fully replace the permissions structure in the token introspection response is a bridge too far in having removed the token profile scaffolding. OAuth has token profiling. There is a use case for just conveying RqP identity claims for achieving *fine-grained* authorization at the edge (along with a use case for conveying RqP identity claims on top of permissions <https://github.com/GluuFederation/oxAuth/issues/342>). UMA permissions on their own only convey "scope-grained" permissions. Can we reuse the UMA profiling capability to allow third parties to replace the permissions structure if they need to? It's already possible to create these (so Gluu could consider doing this)." I think these are the various questions: 1. Whether token introspection (Sec 3.4 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-07.html#check-rpt-status>) should be mandatory for the AS to implement or not 2. Whether the *form* of the AS response (documented in Sec 3.4.2 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-07.html#uma-bearer-token-profile>), with the permissions property, must be used as-is or can be replaced with a different structure 3. Whether the permissions array should be able to be empty or not 4. What type of access token an RPT is ---- *Question 1:* In UMA1 this was mandatory to implement (MTI), but in rev 07 this has been softened. It just says that, depending on what the AS supports, the RS "MAY" validate the token locally or introspect it at the AS. We're sort of in an in-between place here. Normally for a binary choice like this, we prefer for the AS to declare its support in a config data flag -- or we make one choice MTI. Of course, having implemented the endpoint, the AS might *still* have *delivered* a self-contained token, in which case the RS still has to unpack the token itself, and it's up to other ecosystem parameters for everyone to figure things out. Sensible options seem to be: - *Option 1a:* Add back language that says the AS MUST implement token introspection. - *Option 1b:* Change the introspection_endpoint property so that it's optional, and when it's not there, it means the AS doesn't support token introspection. *(I have a preference for 1a for interop, on the assumption that an AS needs to be an always-on kind of service, but if someone can think of use cases for AS types that don't have to be, by all means speak up!)* ---- *Questions 2 and 3:* In rev 07, assuming token introspection is being used, then the AS has to produce the prescribed *form*, with the permissions property, same as UMA1. (Extensions to the form are possible.) The OAuth world today is full of "narrow ecosystems" exclusively -- so those AS/RS combinations that use something proprietary that doesn't "speak token introspection" and draws outside the lines of the official JSON object don't care about UMA. But UMA can be used in narrow ecosystems too, and some of those might want to replace or mess with the permissions structure, as we've discussed. We can't exactly force people to define an extension spec. Perhaps inadvertently, we've allowed the contents of the permissions array to be empty, which provides a "way out" of using the permissions structure, but that seems a bit ugly. We discussed at least encouraging declaration of extensions through uma_profile config data. Sensible options seem to be: - *Option 2/3a:* Keep the permissions property REQUIRED and the objects in the permission array ZERO OR MORE. - *Option 2/3b:* Keep the permissions property REQUIRED but change the objects in the permission array to ONE OR MORE. This forces use of the permissions/permission structure even if it's extended to add stuff. That is, it's more rigid than UMA1. - *Option 2/3c:* Change the permissions property to be OPTIONAL but keep the objects in the permission array as ZERO OR MORE. This removes all interop certainty of the UMA1 version. - Option 2/3d: Change the permissions property to be OPTIONAL and change the objects in the permission array to be ONE OR MORE. This perfectly flips the logic, so that the *structure as a whole* is optional, but if it's present, it has to be used *in earnest*. More commentary: The idea behind options 2/3a and 2/3d, where there's a possible absence of any permissions, is that the spec could say explicitly that the AS could substitute an alternate structure for conveying authorization results -- e.g., other information about the requesting party, client, or other contextual factors that they want the RS to know about -- and it's RECOMMENDED to define an extension profile if they're operating in a loosely coupled environment. *(My preference is 2/3d, in combination with AS support for token introspection and the permissions structure being MTI.)* In addition to this: - *I propose:* Change the name of *permission_scopes* inside permissions to *resource_scopes*. We changed this only once we started working on UMA2, to reduce the confusion between the original token introspection structure's "scope" structure (which we forbid) and our original "scopes" structure in UMA1. ---- *Question 4:* OAuth defines <https://tools.ietf.org/html/rfc6749#section-7.1> the notion of "access token types", and there's even an IANA registry <https://tools.ietf.org/html/rfc6750#section-6.1.1> for them in 6750 (that's where "bearer" is defined; "mac" has its own expired I-D <https://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05>). There's the PoP RFC <https://tools.ietf.org/html/rfc7800> too. We should be leverage OAuth's own system of access token extensibility as much as possible. I inadvertently took out a definition of what UMA's RPTs look like on the wire, which actually perfectly simulated OAuth's bearer tokens on the wire, when going from 06 to 07. - *I propose: *Explicitly declare UMA RPTs to be OAuth bearer tokens and add back the example(s) from rev 06 along these lines. *Eve Maler* Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl