- WG-UMA - mailman.kantarainitiative.org

Token profiling and requiring the permissions structure in token introspection response
by Eve Maler 10 Nov '16

10 Nov '16

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-st…> pretty heavily, and Sec 7.1.1 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-07.html#redirect-thr…>'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-st…>) 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-t…>), 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

1 0

Draft minutes of UMA telecon 2016-11-10
by Eve Maler 10 Nov '16

10 Nov '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-11-10 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2016-10-13 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-10-13> , 2016-11-03 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-11-03>: APPROVED by unanimous consent. Logistics We *ARE* meeting next week, but Friday at 9am PT, not Thursday. That's right after the Legal call. Work on UMA.next issues Syntax changes as listed above are confirmed OK. The new invalid_scope error is OK. We don't have to say "*protected* resource" all the time, particularly in syntax. 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). We have some outstanding questions around the token profiling question and the permissions structure. Eve will send an email outlining these with all the options she can think of and possibly making some proposals so we can decide by next week. (She'll include the Sec Consid point from 7.1.1.) *AI:* Eve: Email about token profiling, as above. Instructions for Core rev 08: - Sec 3.4: The RS has the option of using cached RPT status results, so include this in the options (has swimlane implications?). This is also an AS TTL strategy thing (including revocation and disconnected RS scenarios, e.g. IoT scenarios), which we should comment on if we haven't already. - Add companion security considerations around TTL for RPTs and permissions, since you need to measure risk and risk appetite based on the RS, the resource itself, and even the nature of the policy conditions etc. Without active revocation infrastructure, the risks are higher. - pat_grant_types_supported: Goes away. Attendees As of 3 Oct 2016, quorum is 6 of 11. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Cigdem, Sarah) 1. Domenico 2. Sal 3. Nagesh 4. Robert 5. Eve 6. Mike 7. Cigdem 8. Sarah Non-voting participants: - Francois - James - Scott F - Kathleen - Arlene - Jin - Colin - John W Regrets: - Andi *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Core spec rev 07 is up
by Eve Maler 09 Nov '16

09 Nov '16

https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-07.html Lots of stuff pushed forward, though not all the rhetorical stuff. I edited the agenda for tomorrow to summarize the key bits that have been done and what we'll discuss and focus on. It would be great if people could review. The edits encompass the commits from Nov 6, 8, and 9: https://github.com/KantaraInitiative/wg-uma/commits/07-edits (Grateful for help tagging this... I'm also hoping to get help prepping the RSR source file so I can start tackling it again. I'm technically on vacation this week -- arrgh...) Most particularly, please note that I haven't yet done the Sec 1 or Sec 3 introductions, which will be the places we'll put some kind of ASCII versions of Dom's diagram work. Getting close, though! Talk to y'all soon. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2016-11-10
by Eve Maler 09 Nov '16

09 Nov '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-11-10 Date and Time - *Thursdays,* 9-10am PT - Skype: +99051000000481 / US +1-805-309-2350 / international lines <https://www.turbobridge.com/join.html> / web calling interface <https://panel.turbobridge.com/webcall/> / code 1782540 - Screen sharing: http://join.me/findthomas - NOTE: do not use the join.me dial-in line - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2016-10-13 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-10-13> , 2016-11-03 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-11-03> - Logistics for upcoming meetings (calendar <http://kantarainitiative.org/confluence/display/uma/Calendar>) and 2016 roadmap <http://kantarainitiative.org/confluence/display/uma/UMA+Roadmap+for+2016> check-in - Next week: *WG meeting on Fri Nov 18* at 9am PT after legal call instead of Thu Nov 17 - Week after: *no WG or legal meeting* due to US holiday - Work on UMA.next issues – Core is up to 06 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-06.html> and should be up to 07 well before the meeting – please review changes ahead of time if possible - The following changes affect syntax: - Removed config data to declare pat and rpt profiles supported (as agreed last time) - requesting party claims endpoint --> claims interaction endpoint (language that affects syntax in endpoint config data ) - resource set --> resource (language that affects syntax in endpoint config data and token introspection returned object format) - New AS-to-client invalid_scope error (because a client can now ask for scopes) To discuss specifically this time: - Set math: See 9-29 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-29> and 10-6 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-10-06>, and the email thread <https://groups.google.com/forum/#!searchin/kantara-initiative-uma-wg/though…> – including... - What scopes should the client ask for, *and why*? (E.g., least-privilege rationale.) What should the mechanism be for asking for scopes for specific protected resources? - What permissions should the RS request on behalf of the client, *and why*? - pat_grant_types_supported: My proposal <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/GVnuVMnoX…> was to remove it. Any further discussion? - claim_token_profiles_supported: My proposal <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/GVnuVMnoX…> was to keep this profiling mechanism, but clean it up and provide two actual profiles or at least credible examples, say, for OIDC ID tokens and SAML assertions. Discussion? - uma_profiles_supported: My proposal <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/GVnuVMnoX…> was to keep this profiling mechanism, but figure out seriously if the extensibility profiles are doing the right job, and include credible examples of extensions and not just extensibility profiles. Discussion? - Is step-up auth the way it was conceived in UMA1 hunky dory according to the claims collection mechanism in UMA2? - Is the (client) registration endpoint's name correct according to the naming pattern used in UMA, and also OAuth and OIDC? - See the latest swimlane <http://www.websequencediagrams.com/files/render?link=Pu0sP0Oe2kjKc2WgdKZd> - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

UMA Authorization process flow (diagram)
by Domenico Catalano 07 Nov '16

07 Nov '16

Hi all, attached a new version of the authorization process flow, using a business process formalism, hoping it’s more accurate. Any comment? Thanks Domenico

1 0

Thoughts on resource set scope "math"
by George Fletcher 06 Nov '16

06 Nov '16

Assumptions: 1. In UMA, scopes are really "per user" rather than per API. Now it is unlikely, and not encouraged, that an RS would produce an API where the scopes are really unique to each user. In most cases it is more likely that the RS will have a set of defined scopes that work across their entire API and hence across all registered resources. 2. For any given resource set, a subset of the full list of the scopes supported by the RS may be registered. Sets of scopes as identified in the meeting notes from 2016-06-02 [1] 1. The universe of scopes the RS has registered for the resource set 2. The scopes the client has registered for at the AS (if it has done this at all) 1. Note that I would add to this that this list of scopes should rather be the list of scopes the AS has determined the client is allowed to request 3. What the RO has attached to the policy for the resource set 4. What the RS requests for at the permission endpoint (in order to get a ticket) 5. The scopes the client requests at the token endpoint Possible algorithm for determining the set of scopes to be issued with a permissions ticket. * The max possible set of scopes that could be returned from the /token endpoint when requesting a token is the "universe of scopes the RS has registered for the resource set" identified by the permissions-ticket * The allowed set of scopes that can be issued by the UMA AS is the INTERSECTION of "universe of scopes [#1]" and the scopes allowed by the RO policy for that resource set [#3]. Let's give this resulting set a number of [#6] {allowed scopes for the resource set} * The list of scopes requested by the client is determined by the INTERSECTION of [#2] and [#5]. Let's give this resulting set a number of [#7] {scopes the client is allowed to request} * The set of requested scopes is the UNION of set [#7] and set [#4]. Let's give this resulting set a number of [#8]. * The max scopes that can be allowed for this access_token request is the INTERSECTION of set [#6] and set [#8]. Mapping this to pseudo-code: Set PossibleScopes = RegisteredResourceSetScopes INTERSECTION ROAllowedScopes Set ClientScopes = ASAllowedClientScopes INTERSECTION ClientRequestedScopes Set RequestedScopes = ClientScopes UNION PermissionTicketScopes Set AllowedScopes = PossibleScopes UNION RequestedScopes Thanks, George [1] https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-02

5 6

AS configuration data "*supported" properties
by Eve Maler 04 Nov '16

04 Nov '16

https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-06.html#am-endpoints We decided in yesterday's call to remove the following properties entirely: *pat_profiles_supported*: TO BE REMOVED in rev 07 *rpt_profiles_supported*: TO BE REMOVED in rev 07 We agreed to discuss what to do about the others, on the principle that defining extensibility points when there's only a single exemplar of a usage of the extensibility point is not a good enough rationale for it. *pat_grant_types_supported*: REMOVE OR KEEP? The OAuth Metadata spec <https://tools.ietf.org/html/draft-ietf-oauth-discovery-04#section-2> defines an optional grant_types_supported property. We could say that since a PAT is an ordinary OAuth access token, an UMA AS could simply leverage OAuth AS metadata in the usual way and use this property if it wants to (or not say anything at all, since a PAT is 100% purebred OAuth). *Proposal*: Remove. *claim_token_profiles_supported*: REMOVE OR KEEP? This ties to Sec 3.6.1 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-06.html#claim-push>. We don't define any claim token profiles ourselves, but -- perhaps dangerously -- provide an example of a format called " http://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken", by which we loosely meant OIDC built-in plus extension claims. I know several UMA implementations have included this, but I have no idea if they're interoperable. *Proposal*: Keep, but seriously clean up the language around HybridIDToken, and possibly supply a couple of real profiles for the obvious ID tokens people would want (canvass implementers for interest in which kinds of tokens). *uma_profiles_supported*: REMOVE OR KEEP? This ties to both Sec 5 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-06.html#comms-profil…> (*extensibility* profiles already defined in the spec, with the intention that various communities would hopefully define *extension* profiles on top of them) and Sec 6 (UMA's framework for third parties to build profiles and extensions, based on SAML's similar one). Since the AS has config data, and right now the RS and client don't really (I guess there's software statements too), there's a bit of a hole regarding what profiles and extensions can formally be expressed. *Proposal*: Keep. Canvass implementers for interest in the extensibility profiles. Ensure that Sec 6 fully includes extensions as well as profiles in its language. Consider whether there's anything to say about software statements, and anything forward-looking to add about other "authorization metadata/config framework" efforts going on. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Upcoming changes to WG and legal subgroup meetings in November
by Eve Maler 03 Nov '16

03 Nov '16

(The legal subgroup is meeting tomorrow as usual; I just sent out the agenda.) NEXT WEEK: The WG is MEETING AS USUAL on Thu Nov 10. Sorry I didn't mention this on today's call, but I needed to CANCEL the legal subgroup meeting for Fri Nov 11. WEEK OF NOV 14: Our Thu Nov 17 WG meeting is MOVED to 9am PT (usual hour) Fri Nov 18. The legal subgroup is meeting as usual on Fri Nov 18 at 8am (just before the moved WG meeting). WEEK OF NOV 21: The WG is NOT MEETING Thu Nov 24 and the legal subgroup is NOT MEETING Fri Nov 25 because of the US Thanksgiving holiday. I've just made these changes in the online calendar <http://kantarainitiative.org/confluence/display/uma/Calendar>. If you're not already subscribed, it's a good idea to do so. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA legal telecon 2016-11-04
by Eve Maler 03 Nov '16

03 Nov '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… Date and Time - *Fridays,* 8-9am PT - Voice: Skype: +99051000000481 / US +1-805-309-2350 / international lines <https://www.turbobridge.com/join.html> / web interface <https://panel.turbobridge.com/webcall/>, code 178-2540# - Screen sharing: http://join.me/findthomas – NOTE: do not use the join.me dial-in line - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar 2016-11-04 - Review <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/rx7yh92Jp…> draft UMA Legal mission statement (and Jim comments), wordsmith, and decide - Review current use cases and plan for building up new ones Attending: ... *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2016-11-03
by Eve Maler 03 Nov '16

03 Nov '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-11-03 MinutesRoll call Quorum was reached. Logistics *We're ON for Thu Nov 10* – regrets from Justin, Andi is unsure. We need to *MOVE our Thu Nov 17 meeting to 9am (usual hour) Fri Nov 18* – regrets from Cigdem, Domenico. We're *NOT MEETING Thu Nov 24 or Fri Nov 25* because of the US Thanksgiving holiday. Approve minutes Approve minutes of UMA telecon 2016-10-13 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-10-13>: Deferred. Work on UMA.next issues "Authorization process": The definition could potentially be improved by breaking the first sentence into two. The second sentence could focus on risk management. Can we define "trust" formally somehow as managing risk? Do we need "trust elevation" anymore? This is a live thread in email. Is the equation "The RO only authorizes access within their risk appetite/tolerance"? Maybe this is where we could point off to the UMA Legal work because it's a complex equation and the RO isn't the only party with risk and liability. Robert notes that part of decision is how you make a good decision. A technical spec's job isn't to describe *all* of this, but it could point off to other resources that go into it. "Authorization process: The process through which the client obtains an RPT from the authorization server in order to access a protected resource. The process has two activities, and these can iterate. One activity is assessing claims and other contextual factors against the resource owner's policy conditions. Another is is collecting claims, which can include both claims pushed from a client and interactively gathered from a requesting party. Suggestion to Domenico for his new flowchart: Try switching input and actor bands, and adding an actor so there's always two. Let's be sure that it's "technically accurate" as much as possible, assuming developers will take it seriously. Andi suggests it will be used more "generically", so maybe we can use it more at a 50K foot level. Regarding "token profiling goes poof": Medication/read 22354546 read Regarding the "*supported" options in the config data: Both Justin's and Cigdem's implementations implement and ignore them! Is there any dissent to pulling pat_profiles_supported and rpt_profiles_supported? Instructions: - Sec 3.5.4: "The fifth error response, need_info, begins *or continues* ..." - Redefine "authorization process" through as two activities/states, and be sure to incorporate "client identity" and any other contextual factors (we used to call this "RqP-independent"). - Undo the "token profiling goes poof" and reconstitute the actual introspection response part; make use of 7662 mandatory. - Remove pat_profiles_supported and rpt_profiles_supported *AI:* Eve: Send separate email threads about all the other "*supported" config data fields and rationales pro and con. Attendees As of 3 Oct 2016, quorum is 6 of 11. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Cigdem, Sarah) 1. Domenico 2. Nagesh 3. Andi 4. Robert 5. Maciej 6. Eve 7. Cigdem 8. Sarah Non-voting participants: - Justin - Francois - Kathleen *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0