November 2016 - WG-UMA - mailman.kantarainitiative.org

Agenda for UMA telecon 2016-11-18 (special Friday meeting just after Legal call)
by Eve Maler 18 Nov '16

18 Nov '16

In the Legal call, I'll have an update from a discussion with Karsten Kinast that we can discuss. ==== http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-11-18 Date and Time - *Special Friday meeting,* 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-11-10 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-11-10> - 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: *no WG or legal meeting* due to US holiday - Week after: normal WG meeting on Dec 1 - Week after that: Eve unavailable on Thu/Fri... - Work on UMA.next issues – Core is up to 08 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-08.html> and RReg is up to 01 <http://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-01.html> – please review changes ahead of time if possible - Besides agreed and expected changes, main changes are: - Removed pat_grant_types_supported per proposal <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/GVnuVMnoX…> - "protection API token" --> "protection API access token" - "permission registration --> "permission request" (rhetorical and syntax) - "permission_scopes" --> "resource_scopes" - "resource set reg" --> "resource reg" (rhetorical and syntax) in RReg spec - Introduction text in Core (incomplete) – please especially review - To discuss specifically this time: - Briefly review Introduction and plan to include high-level diagram - Discuss "token profiling" proposal to: - Make token introspection permissions structure optional - Require its array to contain one or more values - Require AS to support token introspection - Require AS to support permissions structure - Recommend development of extensions for alternative introspection structures - Even if token introspection isn’t used, can/should we require the ability for a locally validatable RPT to operate at a “permissions” grain somehow? - Need to say something about RReg taking place in the context of a resource owner? Is it always done in that context? Doesn't it depend on the RReg security mechanism used? - 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*? - 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? - Need to have IANA registry entries for both old uma-configuration and uma2-configuration? - Shoebox endpoint - Claims hashing - 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

Core rev 08 is out; sorry for the delay
by Eve Maler 18 Nov '16

18 Nov '16

Just back from Paris by way of Reykjavik. :-) I'd hoped to get this rev up before that trip, but at least I got good use of the laptop battery on the way back... http://docs.kantarainitiative.org/uma/ed/uma-core-2.0-08.html I'm just about to send out the agenda for tomorrow. It's got lots of specifics for us to review and discuss. Hopefully east coast, European, and early-riser west coast people will have a quick chance to take a look. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Reminder: WG call has moved to Friday this week / New RReg draft up
by Eve Maler 16 Nov '16

16 Nov '16

Don't forget that this week's WG call is Friday instead of Thursday, after the Legal call; please see the calendar <http://kantarainitiative.org/confluence/display/uma/Calendar> if in doubt. ==== In other news, I've managed to publish a new version of the RReg (used to be RSR) spec, rev 01 <https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-01.html>, a mere three months after rev 00. The main edits were squished into one big commit <https://github.com/KantaraInitiative/wg-uma/commit/81814413b7ccb39576bc7a5c…>. Nothing all that huge changed and it's not that deep or philosophical a spec, but I'll list some food-for-thought topics here that I plan to add to the agenda for Friday: 1. Is this really and truly a spec that's independent of UMA ("OAuth" RReg)? Does it need an extension grant or token introspection extension of some kind to function properly? 2. We currently force scope URIs (vs. plain strings) to resolve to a scope description document, though we impose no testable-assertion penalty if this is violated. Do we want to keep this a MUST? 3. The Core spec allows RS's to manage protection of any resources it likes at the "edge", away from UMA. Should we say something explicitly in RReg as well about this option, sanctioning the option of letting an RS leave out any resources, and scopes of resources, that it wants? 4. Do we need to say something about resource registration taking place in the context of a resource owner or at least in the context of the trust relationship of an AS and RS? For UMA, it's all about the PAT context. This comes back to question 1... *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Issue #256: Consider the naming of entities and concepts: configuration/discovery
by Eve Maler 14 Nov '16

14 Nov '16

https://github.com/KantaraInitiative/wg-uma/issues/256 This is one of a series of messages meant for discussion of naming of entities and concepts. This message consolidates *configuration/discovery* terms from the GitHub issue: - configuration data (original) - discovery document (proposed; might change the name of the directory -- or should it be file? -- where the metadata resides) For now, let's please discuss only in email, unless we're all somehow magically aligned by the time we get to the next call. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 4

Issue #256: Consider the naming of entities and concepts: authorization/claims terms
by Eve Maler 14 Nov '16

14 Nov '16

https://github.com/KantaraInitiative/wg-uma/issues/256 This is one of a series of messages meant for discussion of naming of entities and concepts. This message consolidates a bunch of *authorization/claims* terms from the GitHub issue: - authorization process (new) - authorization interface (new) - authorization API (obsolete) - UMA grant (new) - trust elevation (still used but some not crazy about it) - gathered claims, claims gathering (intended to be used just for interactive) - requesting party claims endpoint (original, sometimes accidentally subbed with "interactive claims-gathering endpoint") - pushed claims, claim pushing - claims collection (sort of new, intended to be used for both interactive and pushed) For now, let's please discuss only in email, unless we're all somehow magically aligned by the time we get to the next call. I'll provide my own thoughts in a followup message. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 6

Applicability of OAuth 2.0 hack to UMA?
by John Wunderlich 13 Nov '16

13 Nov '16

Has anyone looked at “Signing into One Billion Mobile LApp Accounts Effortlessly with OAuth 2.0. <https://www.blackhat.com/docs/eu-16/materials/eu-16-Yang-Signing-Into-Billi…>” for applicability to UMA? Sincerely, John Wunderlich @PrivacyCDN <https://twitter.com/PrivacyCDN> Call: +1 (647) 669-4749 eMail: john(a)wunderlich.ca -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

6 6

Issue #256: Consider the naming of entities and concepts: major entity/concept terms
by Eve Maler 11 Nov '16

11 Nov '16

https://github.com/KantaraInitiative/wg-uma/issues/256 This is one of a series of messages meant for discussion of naming of entities and concepts. This message consolidates a bunch of *major entity/concept* terms from the GitHub issue: - resource owner (RO) (original; from OAuth) - requesting party (RqP) (original; confusion with identity "RP") - resource server (RS) (enhanced OAuth version; also acts as OAuth client; confusion with identity "RP") - client (enhanced OAuth version; also acts as OAuth client; confusion with identity "RP") - authorization server (AS) (enhanced OAuth version) - resource set (original), protected resource, resource (colloquial) - scopes (also appeared in the *authorization/claims* message) For now, let's please discuss only in email, unless we're all somehow magically aligned by the time we get to the next call. I'll provide my own thoughts in a followup message. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 7

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