- WG-UMA - mailman.kantarainitiative.org

New 02 rev of UMA Core
by Eve Maler 27 Sep '16

27 Sep '16

Justin's latest edits are incorporated.* https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-02.html Please review for "persisted claims token (PCT)", rotated permission ticket, and other related language. On Thursday we'll dig in to UMA grant design and set math. I'd like us to think about how how complete we can make this before IIW. *Maciej struggled with the spreadsheet and I struggled with XMLmind, and we both have been losing so far. :-) Therefore, what you'll see here has errors where proper RFC references should be, and I decided not to bother updating the publication date just to have a whole bunch of other pointless changes (spaces in empty elements) show up at the same time. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

MPD Rewrites
by Justin Richer 24 Sep '16

24 Sep '16

As requested on the last call, I’ve taken an axe to the UMA specification and incorporated text and concepts from the MPD proposal sets. The new spec text (still rough in many spots) is available here: https://github.com/jricher/wg-uma/commits/mpd-rewrite <https://github.com/jricher/wg-uma/commits/mpd-rewrite> Specifically, this difference set: https://github.com/jricher/wg-uma/commit/ae82fe797229827e0cd3dfc2264268ea36… <https://github.com/jricher/wg-uma/commit/ae82fe797229827e0cd3dfc2264268ea36…> I added language on PCT’s (based on the model I outlined in the other thread), I changed the “scopes” parameter to “permission_scopes” as in the MPD implementation, I changed the interaction and examples to use the token endpoint for the RPT request, I moved the discovery document to .well-known/uma2-configuration and fixed a couple parameters, and I incorporated the rotating ticket mechanism from the security extension we wrote this spring. Sorry it’s all in one commit, but I found it easier on my end to just plow through the whole spec. — Justin

2 1

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

23 Sep '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2016-09-23 - Working session on User-Managed Access (UMA) in Contractual and Regulatory Contexts <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…> - Today's meeting is at 10am PT/1pm ET/6pm UK/7pm CET - Same bat channel Attending: Eve, Ann, Scott D, John W, Mary Eve's slides that show four "BLT use cases" are here <http://www.slideshare.net/ForgeRock/usermanaged-access-why-and-how-access-c…>. In UC3 (Alice oversees 12-year-old Susie's online usage), there are different kinds of harm that we're trying to protect against. Some are about inbound data sharing, some are outbound data sharing, some have other natures. Also, the diagram doesn't show that Susie is expected to be able to use her UMA client in turn as a downstream UMA RS. In some contexts/jurisdictions, there are rights that Susie would have that need to be protected as well. The "age of majority" subtleties hinge on various ages, and it can be a combination of a legal and a contractual status. We've imagined that it would be a technical status (PAT revocation) that would reify the status change that would allow "timing in" of legal capacity. Though the primer probably wouldn't go here, and our UC diagrams are static, we could theoretically write UMA profiles that specify "state changes" such as PAT revocations and such that are legal capacity-dependent, perhaps in some complex workflow relationship with the type of the digital resource being protected. This could even enable "smart regulation". The Past Is a Foreign Country <https://www.amazon.com/Past-Foreign-Country-Revisited-ebook/dp/B00IO0E2FM/r…> – can we overcome our biases about how we've done things previously? We suspect that this challenge is actually operational, rather than heavily theoretical. Once an AS knows the age of a resource owner, and an RS can share well-known semantics about a resource set type with the AS, then policy conditions can connect the dots about jurisdictional constraints on sharing information about, say, pregnancy test results once the resource owner is "of age". Thinking modestly once again [image: (smile)], we do have to prepare for the technical layer to fail gracefully in a privacy-protective fashion as the other layers vary. The technical layer (modulo our question about a client turning around and becoming a downstream RS?) stays the same no matter what happens at the other layers around it. The legal capacity picture around it is *really interesting:* - When you're young, you time-in to legal capacity - When you're old, you time-out of it - At some times in life, you might intermittently go into and out of it - Drunk or otherwise impaired (meds/drugs, distracted, tired) - Coerced (gun to your head) - Dementia but functioning - In Ontario law, there is a notion of "assumed implied consent" that lets someone take over for you if you're bleeding out on the ER table – a kind of break-glass right How can we model this? Is it all down to revocation of the PAT? UMA doesn't have a notion of multiple resource owners, which presents a bit of a challenge. John shared this blog post <http://blog.priv.gc.ca/index.php/2016/09/22/how-fit-is-your-gadget-putting-…> about privacy and fitness devices. We had been thinking in terms of Ts & Cs that are relatively static for the (mostly) pairwise relationships between parties. Where could "smart contracts" introduce dynamism/configurability? The obvious place this had come in was in trust elevation, which is a Grantor/Grantee relationship. Where else could it apply? See our "trust relationship" discussions in the April notes (start here <http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note…> and work back). Counterintuitively, injecting more democracy into previous feudal systems has the effect of creating more dynamic stability. That's what we're talking about here. (Not to put too fine a point on it. [image: (smile)] ) *AI:* Scott D: Take Eve's slides containing four use cases and "translate the technical stability into a persuadable view of stability and value in other regimes" for use in the primer. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA legal telecon 2016-09-23 (today) -- two hours later than usual
by Eve Maler 23 Sep '16

23 Sep '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… Date and Time - *Fridays* - 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-23 - Working session on User-Managed Access (UMA) in Contractual and Regulatory Contexts <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…> - Today's meeting is at 10am PT/1pm ET/6pm UK/7pm CET - Same bat channel *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

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 21 Sep '16

21 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