- WG-UMA - mailman.kantarainitiative.org

No WG or legal call next week, Sep 15/16
by Eve Maler 10 Sep '16

10 Sep '16

Instead, please review the meeting minutes, notes, and primer link sent out, and I'll try to get to UMA Core draft 02 for review (and pull requests :-) ) as well. Thanks! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2016-09-09
by Eve Maler 09 Sep '16

09 Sep '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-09 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2016-09-01 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-01>: Deferred. Logistics Meeting next week? No, we are not meeting next week. Work on UMA.next issues - Core is up to 01 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-01.html> - RSR is up to 00 <https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-00.html> - UMA refresh/saved consent/persisted claims token logic – refer to 2016-09-01 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-01> notes - UMA grant flow requirements – refer to 2016-08-18 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-08-18> notes - Client awareness of scopes and set math – refer to 2016-06-02 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-02> , 2016-06-16 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-16?…>, and 2016-08-04 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-08-04> notes Persisted claims token Let's use this name for now and do the big "names for everything" roundup when we get to it. MITREid Connect implemented the original UMA RPT as a "true" OAuth access token – so, nothing special about the "UMA bearer token profile". And since UMA Core didn't say anything one way or another about refresh tokens, they didn't implement that. Pros and cons: PAT/RPT/AAT/(no RPT refresh token): - Uses straight OAuth to gather the RqP's authorization. - Requires implementation of the AAT. - Requires ReqP authentication. - Requires that authentication as soon as the RqP shows up to the AS. - AAT interferes with "wide ecosystem" use cases (though this isn't the only barrier to them). - Has an "extra" endpoint (RPT endpoint). PAT/RPT/RPT refresh token/persisted claims token: (Note that the AAT really is gone, though there are a few rogue mentions still in the spec and there's more surgery to do, e.g. a true "UMA grant" flow specification needs to be written.) - Requires implementing a minimum of two tokens. (Optionality.) A full implementation could implement the PCT as well. - One fewer endpoint overall. (Simplicity.) - This paradigm doesn't actually reduce the number of tokens. - Don't know yet about all aspects of PCT design. Is a new invented thing. Andi notes that if we've got "consent" tokens (mindful that we want to avoid that word!) floating around, we want to think about auditability. So it's time for a good pow-wow with the CIS WG, and also for discussing "notification endpoints" and such. We're agreed that the "PCT" would be best applied for both interactively gathered and pushed claims both. Now, to examine how smooth or complex the RqP interaction could get. We looked at Eve's analysis of how "compressed" or "onerous" the flows could be. Justin notes that the RqP's authorization is not required for the token itself to persist the claims of both categories, so the "onerous" picture in the PCT case isn't really right. In other words, the RqP doesn't need an account at the AS. 't envisions a special claim that represents the RqP's authorization – that is, a claim with special semantics. Should we have a separate spec for this special claim? It's sort of internal to the AS, so maybe we just define it right in the same UMA Core spec, and don't put it in any standardized registry. Andi feedback: He'd like a single restatement of what we're trying to solve, why the existing design doesn't solve the problem, and why the new redesign does (we think) solve the problem. What are the security risks? What are the privacy risks? Would PII be leaked? What are the audibility and traceability characteristics? What are the performance characteristics? Let's do swimlanes comparing them. Justin might be able to "build the blasted thing" and Eve can commit to doing the foregoing explanation. We might be tantamount to spec'ing this as well. Let's do all this analysis in email. Attendees As of 31 Aug 2016, quorum is 6 of 10. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Sarah) 1. Domenico 2. Andi 3. Maciej 4. Eve 5. Mike 6. Sarah Non-voting participants: - François - Justin - Adrian - Kathleen *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA legal telecon 2016-09-09
by Eve Maler 09 Sep '16

09 Sep '16

We're meeting at our normal time, and this week's WG call has been moved to follow in the next hour (on the same dial-in). 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-09-09 - Working session on User-Managed Access (UMA) in Contractual and Regulatory Contexts <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…> *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

UMA Tokens visualization
by Domenico Catalano 09 Sep '16

09 Sep '16

Hi all, the attached picture shows all the UMA tokens involved in each "triangular interaction", including the Id Token for a claims gathering through OIDC. Is there an analogy between PCT (Persistent Claims Token) and the SAML session token profile <https://www.oasis-open.org/committees/document.php?document_id=43741&wg_abb…> ? I hope this can help for the discussion. Thanks. Domenico

1 0

Agenda for UMA telecon FRIDAY 2016-09-09 (after UMA legal call)
by Eve Maler 07 Sep '16

07 Sep '16

(Feel free to discuss our upcoming agenda issues on the list until we get to Friday...) http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-09 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-09-01 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-01> - Logistics - Meeting next week? - Work on UMA.next issues - Core is up to 01 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-01.html> - RSR is up to 00 <https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-00.html> - UMA refresh/saved consent/persisted claims token logic – refer to 2016-09-01 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-01> notes for design questions - UMA grant flow requirements – refer to 2016-08-18 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-08-18> notes - Client awareness of scopes and set math – refer to 2016-06-02 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-02> , 2016-06-16 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-16?…>, and 2016-08-04 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-08-04> notes - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Offering an "UMAnitarian APAC sync" meeting
by Eve Maler 07 Sep '16

07 Sep '16

Hi folks-- After having a chance to meet several UMAnitarians face-to-face while in Australia recently (and what a good time that was), I was reminded that we hadn't held an "APAC sync" meeting in quite a while. So I thought I'd offer up the chance to hold one again -- if not regularly (we had a fortnightly meeting series that went for a long while, but then it petered out), then perhaps just an ad hoc one to give people a chance to catch up and weigh in on all the stuff going on. For all those in the southern hemisphere who might be interested but can't normally join our meetings, can you drop me a private note by the end of this week and let me know: - Are you interested in technical topics (e.g. our current spec wrangling), legal topics (e.g. the primer and "model clause" work), or both? - What days/time ranges are best for you? Please indicate your time zone - If you had the chance to attend sync meetings regularly, would you? - No, c'mon really, would you? Be honest -- this is for posterity :-) I'll figure out what's what, and if there's enough interest, I'll set something up... *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

3 3

Notes from UMA legal telecon 2016-09-02
by Eve Maler 05 Sep '16

05 Sep '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2016-09-02 - Working session on User-Managed Access (UMA) in Contractual and Regulatory Contexts <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…> - Eve will try to press ahead with lots of editing AIs prior to the call - Adrian and Kathleen have sent various suggestions in list/private email in the last month we should review Attending: Eve, Kathleen, Ann, John W, Mary, Jim We did a ton of work in the document. If you haven't seen it, the latest version of the slides with the "legal use cases" is here <http://www.slideshare.net/ForgeRock/usermanaged-access-why-and-how-access-c…>. Please feel free to share it. See also Jim's CommonAccord capture of the GDPR <http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu/europa/eur-lex…> . *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

8 23

Agenda for UMA legal telecon 2016-09-02
by Eve Maler 02 Sep '16

02 Sep '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-09-02 - Working session on User-Managed Access (UMA) in Contractual and Regulatory Contexts <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…> - Eve will try to press ahead with lots of editing AIs prior to the call - Adrian and Kathleen have sent various suggestions in list/private email in the last month we should review *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Thinking about shifting the Thu Sep 8 call to Fri Sep 9
by Eve Maler 01 Sep '16

01 Sep '16

We've been making pretty good "dog days progress" despite a few interruptions. *This week we definitely meet as normal* for the WG call on Thu Sep 1 and the legal call on Fri Sep 2. I've just had a conflict arise for the following week, and wonder if we should shift our call *from Thu Sep 8, 9am PT to Fri Sep 9, 9am PT*, such that the legal call would be followed by the WG call. Can I get any *"amens" in private email*? I'll reschedule if it looks viable. Unfortunately, my upcoming work travel schedule looks as insane as the IIW/EIC/CIS season did. So as to avoid lots of cancellations, *would a general "backup time" as outlined above* be useful in a pinch? Please *let me know* what you think of that option in your response too. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 1

Draft minutes of UMA telecon 2016-09-01 (note: next week's meeting is on Friday)
by Eve Maler 01 Sep '16

01 Sep '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-01 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2016-08-16 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-08-18>: APPROVED by unanimous consent. Logistics Eve will move next week's call to Friday, same time. Sorry in advance for the hassles! Review latest editors' draft specs - Core is up to 01 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-01.html> - RSR is up to 00 <https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-00.html> - UMA refresh/saved consent/persisted claims token? The AAT, as was (in today's UMA), has been awkward because it forces early binding of the RqP/AS relationship, it forces (for all practical purposes) the RO's AS to have a persisted account for the RqP, and it forces the RqP to have an identifier at this AS. It's rather too centralized and too soon. But removing the AAT is too lossy because the notion of capturing the RqP's approval has gone away. Then again, ... John W calls the token thingie we're trying to build a "nightclub stamp" vs. a heavier credential like a passport or just a typical login credential. The AS can make the saved preference as light (e.g. it doesn't have to have a local login at all, or force its creation immediately at old-AAT time) or as heavy (it could impose it relatively soon) as it needs to. It can be longer than a "login session" because it's supposed to be static and attached to the lifetime of an RPT (or whatever we end up calling an RPT). Justin's latest email seems to be saying that the AAT couldn't possibly let the RqP authorize the pushing of *specific* claims, only let them authorize the pushing of any claims willy nilly. Let's find out if things could be any different in the future. (See the "wide ecosystem challenge analysis <https://docs.google.com/document/d/1lJXDFzlq8j-m0f8mELjqYcX6PPcYSjOuxiGHzwU…>" doc.) How do we solve this without reinventing "backwards UMA" at Alice's AS on Bob's behalf? Ideally, if Bob actually has an AS protecting his (say) attributes/identity claims, then an UMA-protected UserInfo endpoint could simply handle Alice's AS (as a claims client/RP) making requests for that information. But in the circumstance where Bob doesn't have an AS, Kathleen is asking where his delegation/consent should be stored. Are we just talking about a lightweight persistence of his preference for convenient UX reasons? If this is consent by Bob for the client to send claims, is "delegation" a better term? We do want to be sure Bob has a good experience, because onerous interaction experiences could force him to give up and seek out "worst practices" for access granting/data sharing with Alice. Adrian asks: Could sharing through a pseudonym or through non-uniquely identifying information be possible? In short, yes, depending on what policy condition/trust elevation capabilities an AS has decided to provide, and depending on the use cases needed. *(we ended the formal call and continued discussing for a bit)* Today, the spec text only accomplishes: - Subsequent token endpoint usage by the client - ...for "pushing of claims" *Design questions for next time:* - Theoretically, we could add something about the opportunity to have the AS interface specify the exact claims that it needs, though the requirement for the client to push only those claims would be in the realm of the AS "telling on the client" after the fact vs. enforcing the client's actions in the moment! Do we want to do that? - Do we also want to add the ability to "save consent" about all the interactive stuff the user either "just did" or "is about to do", or both? And if so, do we want to say anything about the order of such operations, or make clear that the AS can do whatever ordering it wants, or say nothing at all about the order? Finally, why *can't* the AAT cover all such interactive approvals as well, as the current V1.0.x spec wording suggests? With the new draft wording, the notion of an "authorization interface" that encompasses the interaction between the AS the the RqP admits a more formal way to describe the RqP's approval that we maybe overstated as being under the authorization API before in Sec 1.3.2. Also, Ishan notes that with this new token thingie, we're back up to "three tokens". So what are the pros and cons of the previous three-token model vs. the new one? - PAT/RPT/AAT: Could use straight OAuth to gather the RqP's authorization. But required RqP authentication, and needed to do it up front as soon as the RqP showed up to the AS. This made true "wide ecosystem" use cases a challenge (though this isn't the only barrier to them). - PAT/RPT/new thingie: (Note that the AAT really is gone, though there are a few rogue mentions still in the spec and there's more surgery to do, e.g. a true "UMA grant" flow specification needs to be written.) This paradigm doesn't actually reduce the number of tokens. But we *believe* AAT removal simplifies UMA and aligns it more closely by leveraging the token endpoint vs. having an RPT endpoint, defers RqP engagement with the AS, and lets the AS choose whether or not to use an authorization/consent saving/account management model with RqPs. There may still be dragons in the design of the new thingie that we don't know about. Simple descriptions of "Bob's experience" before and after (comments welcome): - *AAT: *Alice shares something with Bob. Through his client app (which already has client credentials at Alice's AS), he attempts access. Depending on the ecosystem and Alice's policy conditions, the process could be as compressed as "Bob already has an account at Alice's AS because everyone in the ecosystem is required to have one, his AAT is created in some implicit fashion (e.g. SAML assertion flow), and any needed claims are automatically pushed as required", or as onerous as the following: 1. If no account at AS (or at a suitable IdP the AS accepts for a federated login): Create one 2. Complete OAuth/OIDC (social login-style) flow to approve client to use this AS 3. Complete any interactive claims-gathering required by the AS (could be multiple NASCAR-involved retrievals) - *New thingie:* Alice shares something with Bob. Through his client app (which already has client credentials at Alice's AS), he attempts access. Depending on Alice's policy conditions, whether trust elevation involves interaction at all, and whether Bob's authorization to will be persisted, the process could be as compressed as "Bob never does anything at the AS, and claims can be pushed totally silently without Bob having an overt relationship with the AS because that's been dealt with out of band" or as onerous as the following: 1. Complete any interactive claims-gathering required by the AS (could be multiple NASCAR-involved retrievals) 2. Potentially complete a form approving specific client-pushed claims, vs. "any claims the client needs to push to effect access to Alice's stuff" (as noted above, not sure if this is enforceable vs. just monitorable) 3. Complete a "save consent" interaction at the AS (likely requires a local or federated login account creation first for persistent claims storage) Link to the slides Eve showed: Webinar from May 2015 <http://kantarainitiative.org/confluence/pages/worddav/preview.action?fileNa…> (see slide 15). Client awareness of scopes and set math See 2016-06-02 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-02> , 2016-06-16 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-16?…>, and 2016-08-04 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-08-04> notes. Last time we said: "Let's discuss client registration for scopes more next time." Ha. [image: (smile)] Attendees As of 31 Aug 2016, quorum is 6 of 10. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Sarah) 1. Domenico 2. Andi 3. Robert 4. Eve 5. Jeffrey 6. Mike 7. Sarah Non-voting participants: - John W - Kathleen - Ishan - Adrian Regrets: - Maciej *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0