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

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

Comments on "Saved Consent Token"
by Domenico Catalano 01 Sep '16

01 Sep '16

Hi all, Here are some considerations/comments about SCT (Saved Consent Token): 1. SCT could be considered as session token or session identifier for managing RqP/Client interactions with AS for the trust elevation process, for keeping transparent the subsequent actions. The use case is when Bob (RqP) attempts to access to a protected resouce, obtaining a RPT+SCT. Later (10 min), when he tries to access to a new protected resource which match the previouse claims policy, having an active session (on AS), the client posts the SCT which proof that he has previously released the claims, avoiding the claims gathering again. 2. As session identifier token, it should follow the three rules: unique, random and encrypted. Validity is important as well. 3. Maybe the name "Saved consent Token" could be confusing because of "consent" word, which recall compliance terminology. I hope this is helpful for the discussion. Domenico Sent from my iPad

4 5