- WG-UMA - mailman.kantarainitiative.org

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

22 Sep '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-22 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> , 2016-09-09 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-09>: APPROVED by acclamation. Persisted claims token discussion Justin has essayed an implementation <https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/commit…>. MatchAllClaimsOnAnyPolicy can pass in a PCT, and takes a union of the claims that are in the ticket and the (optional) PCT. PCT creation is straightforward (though not quite working yet because of a particular upstream library limitation). This basically tests what has to change, and the delta is relatively minimal (after having yanked out AATs and switched to using the OAuth endpoints vs. the RPT endpoint). The AAT required a requesting party to authorize usage of the authorization API, which came bundled with the ability to optimize future trust elevation processes. No local AS account was required, though this might be a common way to do things. It used OAuth, and thus the RqP was required to act as an OAuth resource owner – which is too identification/authentication focused. We are now considering breaking apart the abilities to: 1. Elevate trust in the requesting party in a variety of ways (not just, say, requiring uniquely identifying authentication, as most OAuth-based account management implementation requires) – which has been a goal of UMA all along with its concept of CBAC 2. Optimize future such processes 3. Enable authorization for such optimization Since there's "no OAuth to lean on" in talking about Bob's authorization for his client's interactions with the AS authorization interface now, what would it mean if the client were to be able to push claims before he could authorize that? This could have happened in OAuth too, e.g. through implicit flows, and employment contracts that okayed SAML assertion flows and the like. Now, we're sort of acknowledging that authorization has always been in the realm of heuristics, but we'll have to be more explicit than we had been previously that deployers need to ensure they're presenting RqPs with the right authorization choices at the right time. The AAT was required and early-bound, and went out of its way to use OAuth's front channel; now it's optional and later-bound, with more options as to timing and UX, and goes out of its way to use OAuth's back channel. We can perhaps get more specific in our instructions for the "UMA grant" (the client-AS interface) vs. the "authorization interface" (everything else). Also, when the RqP isn't an end-user but rather operating a client autonomously, we've found a more elegant way to accommodate both "legal persons" and "natural persons", as the former don't go around authenticating. Domenico's new graphic <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/ZvcYx3ilO…> captures these concepts nicely. Spec instructions: - Justin to propose PCT text by end of week. Attendees As of 31 Aug 2016, quorum is 6 of 10. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Sarah) 1. Domenico 2. Sal 3. Nagesh 4. Andi 5. Robert 6. Eve 7. Mike 8. Sarah Non-voting participants: - John W - Andrew - Scott F - James - Jin - Justin - Arlene - Ishan - *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Okay to slide our legal call on Friday out by two hours?
by Eve Maler 21 Sep '16

21 Sep '16

Hi folks-- Apologies, but I've been called into a meeting on Friday that will keep me from our regular legal telecon time. I can offer the hour of 10am PT/1pm ET/6pm UK/7pm CET (extra horrible for non-US people, I'm afraid), and it looks clear on the Kantara calendar. Can I get a sense of who's able to join if I move the hour? Please respond by Thursday night. I'll plan to reserve that hour for Primer/model text work regardless. Thanks! Eve (sent from my iPhone, possibly with Siri's "help": +1-425-345-6756)

1 0

Persisted claims token language
by Eve Maler 21 Sep '16

21 Sep '16

We're having trouble with the XML editor, so in lieu of a properly published -02, here is a proposal for some revised PCT language snippets for consideration. Latest draft is Core 01 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-01.html>. *GENERAL ISSUES/COMMENTS:* - We're not talking terminology yet, but note that we have a thing called a "claim token", and it maps to something very different from a "persisted claims token". - We've previously used "trust elevation" as the generic term on top of claims-gathering, step-up authentication, and whatever extension methods might come along. We've now got a model where claims are pretty much everything. In terms of specification, what's the right phrase? Rhetorically, trust elevation has been pretty useful, but if we switch, we'd just need to find a phrase for claims-*something* because "claims-gathering" so far has meant the interactive version, vs. "pushing". Claims collection? (Sounds like the insurance business or something.) - Note that I've avoided "consent" in favor of "authorization", a la OAuth. It seems to work fine. *Sec 1.2, Terminology* persisted claims token (PCT) A correlation handle, conveyed from an authorization server to a client and back, representing the interactively gathered authorization of an end-user requesting party during this trust elevation process for persisting any claims pushed and/or interactively gathered for the authorization server's own potential use in future trust elevation processes. *ISSUES:* - Is "this trust elevation process" clear? Intent is that it means one "run" of the protocol, with as many claims as required in phase 2 to get to phase 3. Should it be "authorization-seeking process" therefore? (This appears in 3.6.3.1 below too.) *Sec 1.3.2, Authorization and Protected Resource Interfaces, UMA Grant, and Requesting Party Token* ... The authorization server MAY enable an end-user requesting party to authorize a client to engage in future trust elevation processes in an optimized fashion using the persisted claims token (PCT) option; see Section 3.5.3 for more information about this option. ... *Sec 3.5, Client Seeks Authorization for Access: The UMA Grant* ... In order to access a protected resource successfully on the requesting party’s behalf, a client needs to present a valid RPT with sufficient authorization data. The client uses the token endpoint to acquire an RPT and optionally to ask for specific scopes it wants, providing the permission ticket it received from the resource server and optionally providing a persisted claims token (PCT) it received from this authorization server. ... *Sec 3.5.1, Client Request to Authorization Server for Requesting Party Token* The client makes a request to the token endpoint by sending the following parameters using the "application/x-www-form-urlencoded" format per [RFC6749] Appendix B with a character encoding of UTF-8 in the HTTP request entity-body: ticket REQUIRED. The permission ticket. rpt OPTIONAL. If the client had included an RPT in its failed access attempt, it MAY include the same RPT here. claim_tokens OPTIONAL. In circumstances where the client needs to provide requesting party claims to the authorization server, it MAY include this value here. See Section 3.6.2 for more information. pct OPTIONAL. In circumstances where the authorization server returned a PCT previously when returning an RPT, the client MAY include the PCT when including the same RPT here. If the client had included an RPT in its failed access attempt, it MAY also provide that RPT in an property in the body. Example of a request message containing an AAT, an RPT, a permission ticket, and a PCT: ... *Sec 3.5.3.1, Authorization Server Response to Client on Authorization Success with Persisted Claims Token* The authorization server MAY return a PCT along with an RPT, subsequent to gathering authorization from an end-user requesting party at the interaction endpoint. The authorization server MUST NOT return a PCT if it has not gathered authorization from the requesting party. See Section 3.6.3.1 for more information about gathering this authorization. The PCT is a securely random, unguessable value that is static for the life of any one RPT with which the authorization server initially issued it. *ISSUE:* - Work to be done: Describe handling of incoming client request for RPT with an SCT in it. Correlate with RPT, ticket, and any claims, add any appropriate error states, and return same SCT back as appropriate. Describe here, or in client request section? Example: HTTP/1.1 200 OK Content-Type: application/json { "rpt": "sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv", "pct": "c2F2ZWRjb25zZW50" } *Sec 3.6.3.1, Authorization Server Gathers Requesting Party Authorization for Persisting Claims* At any time during interactive claims-gathering, the authorization server MAY gather authorization from an end-user requesting party for persisting any claims that are pushed and/or interactively gathered during this trust elevation process for its own potential use in future trust elevation processes. If the authorization server has gathered this authorization, then it MUST generate a PCT to accompany an RPT to represent that authorization (see Section 3.5.3.1 for information on generating and using the PCT). NOTE: In order to manage the claims' persistence, it is likely that an authorization server will need to associate them with an account or profile for the requesting party. However, there is no requirement for the authorization server to present the requesting party with local account registration or authentication options; it could use federated account management techniques such as social sign-in instead. *ISSUES:* - Here and in 3.5.3.1, I've tried out language that assumes the AS MUST generate the PCT if it gathered the authorization. Does this work? - I was trying to think of how to specify a specific claim to gather to represent authorization, but since -- as we discussed -- it's both gathered and consumed by the AS, does it make sense to make it a formal claim, or can it remain in the squishy realm of "gathered authorization"? Is there value in specifying it as a formal semantic? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

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

20 Sep '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-22 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-09-01 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-01> , 2016-09-09 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-09> - 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> - Persisted claims token language proposal - Set math - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Is Privacy Policy Language Irrelevant to Consumers...
by John Wunderlich 17 Sep '16

17 Sep '16

FYI (without implying endorsement): 'Our study shows that courts and laypeople can understand the same privacy policy language quite differently. Taken together, these results provide important evidence for the propositions that (1) social norms and user experiences with technological applications, not privacy policies, will drive users’ understanding of the nature of their bargain with firms, that (2) this is the case even when users read those policies reasonably carefully, that (3) most users of email and social networking sites believe that Facebook, Yahoo, and Google are authorized to engage in controversial and invasive practices implicating user privacy, and that (4) there is presently little reason to expect the development of a robust market for premium privacy-protective email and social networking applications in the United States.' http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2838449 John Wunderlich, Sent frum a mobile device, Pleez 4give speling erurz "...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin -- 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.

1 0

Reminder: No WG or legal meeting this week
by Eve Maler 15 Sep '16

15 Sep '16

However, I hope to get Core editor draft -02 out before/by the weekend. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

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

12 Sep '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 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…> Attending: Eve, Ann, Kathleen, John W, Adrian, Scott D We discussed Eve's new slide describing "key benefits to users" at a high level as a potential way of fleshing out the next subsection of the primer. - Not just opt-in or opt-out when asked - Sharing, unsharing, and editing of sharing preferences allowed at any time, without external influence - Possible to offer a service that centralizes sharing preference management across data services for user convenience - The central service doesn’t see any of the data - It acts on the user’s policy instructions when others attempt access to data services - The user can choose to share whatever “grain” of access each data service offers - Such as read vs. write, or weight vs. fat mass We've now added and wordsmithed this. Instead of the spiral or the simplified spiral in the primer, John suggests a very friendly version of the "three phases" paradigm (as suggested by Adrian) that's already explained in the spec <https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html#introduction>. He will sketch what's he's thinking of, and we'll ask Domenico to turn it into something beautiful! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

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

09 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