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

Thoughts on resource set scope "math"
by George Fletcher 06 Nov '16

06 Nov '16

Assumptions: 1. In UMA, scopes are really "per user" rather than per API. Now it is unlikely, and not encouraged, that an RS would produce an API where the scopes are really unique to each user. In most cases it is more likely that the RS will have a set of defined scopes that work across their entire API and hence across all registered resources. 2. For any given resource set, a subset of the full list of the scopes supported by the RS may be registered. Sets of scopes as identified in the meeting notes from 2016-06-02 [1] 1. The universe of scopes the RS has registered for the resource set 2. The scopes the client has registered for at the AS (if it has done this at all) 1. Note that I would add to this that this list of scopes should rather be the list of scopes the AS has determined the client is allowed to request 3. What the RO has attached to the policy for the resource set 4. What the RS requests for at the permission endpoint (in order to get a ticket) 5. The scopes the client requests at the token endpoint Possible algorithm for determining the set of scopes to be issued with a permissions ticket. * The max possible set of scopes that could be returned from the /token endpoint when requesting a token is the "universe of scopes the RS has registered for the resource set" identified by the permissions-ticket * The allowed set of scopes that can be issued by the UMA AS is the INTERSECTION of "universe of scopes [#1]" and the scopes allowed by the RO policy for that resource set [#3]. Let's give this resulting set a number of [#6] {allowed scopes for the resource set} * The list of scopes requested by the client is determined by the INTERSECTION of [#2] and [#5]. Let's give this resulting set a number of [#7] {scopes the client is allowed to request} * The set of requested scopes is the UNION of set [#7] and set [#4]. Let's give this resulting set a number of [#8]. * The max scopes that can be allowed for this access_token request is the INTERSECTION of set [#6] and set [#8]. Mapping this to pseudo-code: Set PossibleScopes = RegisteredResourceSetScopes INTERSECTION ROAllowedScopes Set ClientScopes = ASAllowedClientScopes INTERSECTION ClientRequestedScopes Set RequestedScopes = ClientScopes UNION PermissionTicketScopes Set AllowedScopes = PossibleScopes UNION RequestedScopes Thanks, George [1] https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-02

5 6

Reminder: UMA APAC sync tomorrow
by Eve Maler 31 Oct '16

31 Oct '16

*Purpose:* Synchronizing on current work with APAC-based participants and gathering their input. *RSVPs* from those in the APAC region (sent directly to me) will be much appreciated! - Sample times: Seattle *Tue Nov 1* 4pm / Sydney *Wed Nov 2* 10am / Wellington *Wed Nov 2* noon - Skype: +99051000000481 - US toll: +1-805-309-2350 - Sydney: +61.2.8014.4647 - Auckland: +64.9.973.0310 - Additional international numbers: https://www.turbobridge.com/ international.html <https://www.google.com/url?q=https%3A%2F%2Fwww.turbobridge.com%2Finternatio…> - Web: https://panel.turbobridge.com/webcall/ <https://www.google.com/url?q=https%3A%2F%2Fpanel.turbobridge.com%2Fwebcall%…> - Code: 178-2540# - Screenshare: http://join.me/findthomas <https://www.google.com/url?q=http%3A%2F%2Fjoin.me%2Ffindthomas&sa=D&ust=147…> (DO NOT USE join.me <https://www.google.com/url?q=http%3A%2F%2Fjoin.me&sa=D&ust=1475556106312000…> dial-in number) - See the calendar entry for more details: http://kantarainitiative.org/ confluence/display/uma/Calendar <http://kantarainitiative.org/confluence/display/uma/Calendar> *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Notes from UMA legal telecon 2016-10-28
by Eve Maler 28 Oct '16

28 Oct '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2016-10-28 - Working session on User-Managed Access (UMA) in Contractual and Regulatory Contexts <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…> - Working through use cases per party in the transaction Attending: Eve, Jeff S, Kathleen *Parking lot* A FAQ would be: What about the identity story? What about where the identity of the RO would be stored vs where the consents would be stored? (thinking of Eve's "scenario 1", which is the UK Blue Badge one) *FAQ idea* We should add FAQs in the doc itself, to answer questions right as they arise in readers' minds, such as: - Once data is unshared, doesn't the recipient already have the data? What happens after that? - This model seems to assume that the enterprise doesn't have any overarching policy itself, and just allows a user to have any sharing policy they wish. Is that correct? - This relates to the larger topic of moving the setting on the continuum of org/individual control more towards the individual; see "blockchain identity use case" - What are specific burdens around PHI vs generic PII? Let's collect these and be as "pointed" as possible in formulating them. We can decide how and where to answer them as we go. *Funded legal analysis and use case work* Eve reached out to Karsten, who likely doesn't have time for the work himself, but who has kindly made himself available to chat with Eve to suggest next steps. She will take action on this. Eve suggests that we should decide, by the end of the year, which deliverables to produce in 2017 as "toolkits" (of some sort) for *all* of the frameworks out there. We discussed our rationale for this: It's to get from our very early stage of UMA adoption to exactly one evolutionary stage further. [image: (smile)] Meaning, we recognize that organizations have incentives to gather data, sometimes act badly towards less-empowered parties (individuals in the main), and so on, and we are looking to demonstrate benefits to those organizations – particularly business and legal audiences -- of the use of UMA through educational materials and reduce friction in using UMA through our "toolkits" (which could be model clauses, could be BCR tools, could be consent receipt templates or profiles, etc.). This is basically a further sharpened mission proposal, if you compare to our 2015 and 2016 versions <http://kantarainitiative.org/confluence/display/uma/UMA+Legal>. *AI:* Eve: Propose a sharpened mission statement on the list for review. Regarding the number of use cases in the world: The hope is that it's more like prepositions (a couple of dozen in English) vs verbs (essentially infinite)! But if there are really any number of them, probably we'll have to identify the most common ones that have lots of examples that hew to a pattern, and leave the "long tail" ones alone. Eve is planning to document these briefly in the wiki and prepare them for our hoped-for legal expert to review, so that we can get to a place where our "toolkits" can supply good tools that map neatly to GDPR interpretations. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Reminder: no WG meeting this week (legal call Friday is still on)
by Eve Maler 25 Oct '16

25 Oct '16

For those at IIW, have a great time! Let us know how everything goes. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Reminder for those convening UMA sessions at IIW
by Eve Maler 23 Oct '16

23 Oct '16

At the beginning of any UMA-related session, please remind other attendees that: - The UMA Work Group (see the wiki at *tinyurl.com/umawg <http://tinyurl.com/umawg>*) is part of the Kantara Initiative - Kantara is a signatory of the OpenStand (see *open-stand.org <http://open-stand.org>*) Principles and embraces an open, transparent, multi-stakeholder community - The Work Group has an IPR policy called "Patent & Copyright: Reciprocal Royalty Free with Opt-Out to Reasonable And Non discriminatory" (see *tinyurl.com/kantaraipr <http://tinyurl.com/kantaraipr>* and the appropriate section) - We strongly recommend that those who wish to *contribute UMA feedback* during or after the session join the WG as a (voting or non-voting) participant, which can be done online (see the *Join* link off the wiki) - Questions about Kantara/IPR can be directed to Colin, and questions about the Work Group can be directed to Eve/@xmlgrrl You can do this in the form of slides, and/or verbally reinforced by session notes, or whatever. Sending this consistent message will really help. Thank you! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Section 7 - Security considerations - bearer tokens
by Cigdem Sengul 22 Oct '16

22 Oct '16

Hello, Eve suggested that I start the discussion about this in the list. Regarding the security concerns about the bearer tokens in the draft, I was curious whether it is worth mentioning Proof-of-Possession (PoP) tokens. In addition, RFC 6750 recommendations may also be referred to in the draft. Thanks, --Cigdem

4 7

Notes from UMA telecon 2016-10-21
by Eve Maler 21 Oct '16

21 Oct '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-10-21 MinutesRoll call Quorum was not reached. Logistics *Next week: no meeting because of IIW!* Have a great time if you're going. Please don't forget to send George comments on his deck, and soon. Approve minutes Approve minutes of UMA telecon 2016-10-13 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-10-13>: Deferred. Work on UMA.next issues *Requesting party claims endpoint:* Eve's proposal for the AS *declaring a requesting party claims endpoint* to the client was that we should pick option 2: both static (in the config data) and dynamic (in the response to the client) methods, with MAY, and with dynamic overriding static if it's present, providing the rationale that static pattern enables the RqP to authorize client pushing of claims and the dynamic pattern enables variable URLs according to the AS's management of its API. Mike notes that OIDC just had a thread <http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20161010/0063…> about a similar matter, regarding scopes. Eve guesses that this specific thread may not be related because it's about a required registration and the interaction between two specs. Is there another thread? Eve proposes spec'ing the text, and if anyone can identify a concern that seems more related, do it by the time rev 06 is out. Eve proposes that the definition of "authorization process" should require that "request_submitted" be more formally defined to have the AS emit a 403, and say that "The authorization server responds with the HTTP 403 (Forbidden) status code.", and the client is free to start another authorization process at a later time. Similarly the other 400s require starting new authorization processes. This makes clear what "persistence" means for a PCT. Mike and Cigdem are supportive. *Authorization interface and UMA grant:* We looked at Dom's first diagram. We requested: - Adding "natural person" and "legal person" icons to both the RO and RqP blocks - Some way of ensuring that inside the AS block: - The protection API concept is associated with the RO-RS-AS tuple - The authorization interface concept is associated with the C-RqP-AS tuple - The UMA grant concept is associated with the C-AS tuple - The PCT is shown as being optional in a nice-looking way - The second canvas with the life cycle should use initial capitals in the text - Attempt resource access - Register requested permission - Authorization process - Authorization assessment - It should also have a small "start" arrow to show that the client attempts access to the resource - The life cycle circle should be a bit smaller to make sure all the outer text shows - Overlay the RPT so that it shows "through" the life cycle (maybe make the circle translucent?) - Keep up the flowcharts according to the swimlane; do as you wish with the life cycle color coding Instructions: - Spec requesting party claims endpoint declaration as indicated above - Spec authorization process definition as indicated above - Create a draft ASCII diagram for the first canvas - Update swimlane *Bearer RPT and PoP tokens:* We didn't get to this, so please weigh in on the list. Eve is happy to try out spec text (and also removing spec text!) in 06 if we hurry on that. 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. Eve 3. Mike 4. Cigdem Non-voting participants: - John Regrets: - James *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Notes from UMA Legal telecon 2016-10-21
by Eve Maler 21 Oct '16

21 Oct '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2016-10-21 - Working session on User-Managed Access (UMA) in Contractual and Regulatory Contexts <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…> - Working through use cases per party in the transaction Attending: Eve, John W, Ann What is the scope of our work (in this subgroup)? The technical layer may or may not change, while the contractual and regulatory layers above may change surrounding it. Our effort to gather use cases is an attempt to literally scope our work for now. Think of this as a "V1" effort of the "UMA legal subgroup" (which perhaps needs a new name because "legal" is too specific?). The use cases are driven by business and influenced by the regulatory environment, and could be implemented with UMA *and*other technologies – e.g., consent receipts, user-submitted terms, JLINC's stuff, etc. Eve's theory: We wanted to do draft model text by 1Q2016. [image: (smile)] But the need for some visible progress by 4Q2016 is getting acute. Evidence: The use case of "delegation of access rights" (think "power of attorney", or positive acceptance of access on behalf of the resource owner, or "I am accepting that you gave me rights to drive this connected car", or "this is a payment API and Alice gives Bob the right to spend money out of her account") keeps coming up. UMA the technical solution says nothing about the API semantics, but the contractual and maybe the regulatory layer (think Open Banking API and PSD2) may say a lot about this. Also, there are some complementary technologies such as Token Exchange <https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-05>, which has an "act_as" semantic, which may have a role at the technical layer. Once upon a time, we had innovated the "Binding Obligations" approach, which enabled a mapping of the non-technical layers to the technical layer where there was a state change so that it's possible to capture that change as part of the chain of evidence (hey, with blockchain/DLT involved??). Sometimes there is no technical state change at the UMA level, but sometimes there is, e.g., a token expires or gets issued or something. And we can start to be more and more clever about that. Keep in mind that "getting access" could mean getting a value of data, or getting access to a stream of data (e.g. Websocket), or getting access so as to insert or delete data. In the world that used to be, only control of "disclosure" mattered. But now, with UMA anyway, API publishers (RS's) are authoritative for what grain of access is possible, and ROs can control what scopes are handed out. What are the constraints on Bob's behavior once he gets access as a "first-party" RqP? 1. Bob is a completely free agent to use the access as he sees fit. 2. Bob is legally or contractually constrained in how he uses the access. 3. Bob is technically constrained in how he uses the access. Eve attempts to make the case that there are fine gradations (referencing her as-yet unpublished permission model taxonomy!) among "ways he uses the access", e.g. onward sharing with third-party grantees such as Charlie, and using it for marketing purposes vs. essential business purposes. She owes the group/the world her taxonomy writeup already. Look at last week's notes for the description of how UMA and a combination of other technologies could address the onward sharing proposition. The "*delegation of access rights*" use case seems to be such a popular one that maybe we should highlight it in our interim publications. What are the realistic options for Bob's use or disclosure of Alice's data he's been exposed to (in this specific case, vs. onward sharing)? "Information wants to be free", generally. To the extent that data is volatile, it loses value over time. To the extent that data is nonvolatile and valuable, helping Alice not to overshare will help, and leveraging wider ecosystems where the business model favors Alice's interests. Beyond that, only nontechnical methods of enforcement will need to be exploited to keep the Bobs in line. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2016-10-21 (special Friday meeting, just after Legal call)
by Eve Maler 20 Oct '16

20 Oct '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-10-21 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 - Logistics for upcoming meetings - Next week: no meeting because of IIW - Approve minutes of UMA telecon 2016-10-13 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-10-13> - Work on UMA.next issues – Core is up to 05 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-05.html> - Requesting party claims endpoint: static declaration, dynamic declaration in response to client, or both? - The authorization interface and the UMA grant - Domenico's latest diagrams - 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> - RPTs, the bearer token profile, and PoP tokens - George thoughts on leveraging UMA error description/URL for more info on specific resource set IDs/scopes at fault in registering a permission? - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

No WG meeting today (Thursday) -- we meet tomorrow (Friday) instead
by Eve Maler 20 Oct '16

20 Oct '16

Please be prepared to weigh in on all the current discussions and text! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0