- WG-UMA - mailman.kantarainitiative.org

Notes from UMA Legal telecon 20017-04-28
by Eve Maler 28 Apr '17

28 Apr '17

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2017-04-28 - Reviewing draft deliverable #3 - "Resource Regulator" role Attending: Eve, John, Adrian, Kathleen, Tim, Mark, Bjorn Review of Move Fast and Break Things <https://www.theguardian.com/books/2017/apr/26/move-fast-and-break-things-jo…>, recommended by John. (We were talking about turpentine and the importance of something stinging in order to tell that it's working – also "if it hurt, do it more often" from Agile.) *Resource Regulator role:* How would we include Resource Regulator in any charts, if we did? A regulator constrains, by law, what some of the other parties do, in a context of enabling others. In other words, it sets rights and responsibilities. And we can't change these. These are jurisdictional. So a regulator is a sort of "god". It's out of band of the UMA protocol and Eve suggests it's also "out of band" of UMA legal because we can't affect regulatory/public law on any reasonable time scale. Here's what we're doing in this subgroup: 1. Building a legal framework... 2. So that we can next build "toolkits" that are friction-reducing building blocks for various contractual mechanisms ("private law")... 3. So that third parties can deploy UMA-enabled service systems in a manner consistent with protecting privacy rights using those contractual mechanisms that adhere to the laws and regulations ("public law") of their jurisdictions Kathleen points out that in the case of HIEs, e.g. in Michigan, there's a kind of blending of private and public law – there's a contract made among HIE participants that includes 42 CFR Part 2 by value. But that was their choice; by-reference would have probably been better. (Hey, CommonAccord would have helped. [image: (smile)] ) Eve's proposal: We can influence interpretation of regulations (especially now when a lot of GDPR etc. guidance is being written), but let's keep "regulator" lowercase since we can't influence written regulations and laws directly. *Consensus* not to uppercase the Resource Regulator party role. *Roles and splitting:* We have roles that mostly stick to the existing UMA technical roles, with the exception of *splitting* Resource Subject and Resource Owner for now. Once we have some model contracts, we can add nuance in splitting roles. Our previous "party" terms of Authorization Server Operator, Resource Server Operator, and Client Operator weren't about splitting but just about acknowledging the different between "software entity" terms and "party to a contract" terms. *Trust frameworks and access federation:* The only ones we are familiar with that exist (that could potentially accommodate UMA-style – party-to-party – user-centric authorization and "consent directives", vs. just opt-in consent) already are trust frameworks for identity federations, except for the emerging Pan-Canadian Trust Framework and the very new health trust framework efforts that Kathleen has mentioned in the BSC context. The latter work puts the data under the patient's control under the "patient's right of access". There are liability shifts which would result in the motivation becoming stronger for appealing to individuals to ask for data for secondary-use purposes. Interesting situation: For a genome, there's more than just one data subject for the same data set! (Should we be talking about reducing friction in "federating access" in UMA-enabled contracts and not yet talk about automation of true "access federations" a la Shibboleth-like automated onboarding of IdPs/RPs?) *Licensing as our legal model:* We need to use some well-understood legal model in our "private law" tools. Effectively there has to be some sort of cascade of rights that the RO gets. As Kathleen points out, the RS will only expose licensing rights that meet their business model. We hope that reducing friction to "doing the right thing". *Tokens:* There are three tokens that come into play: - Requesting party token (RPT) - required - The RqP is able to revoke this through the OAuth token revocation mechanism. - Protection API access token - required - The RO is able to revoke this through the OAuth token revocation mechanism. - Persisted claims token (PCT) - optional - The RqP is able to revoke this through the OAuth token revocation mechanism. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Reminder: UMA Legal call tomorrow (Friday) 8am PT
by Eve Maler 27 Apr '17

27 Apr '17

Dial-in and screenshare: http://join.me/findthomas We'll be discussing Tim's updated chart (attached) and the Resource Regulator topic. :-) Thanks, Tim! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Notes from UMA Legal telecon 2017-04-21
by Eve Maler 27 Apr '17

27 Apr '17

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2017-04-21 - Reviewing draft deliverable #2 Attending: Eve, Tim, John, Mark Tim's insight around identifying the "harms" to the parties in the #2 exercise helped guide the development of the draft deliverables we're looking at today. John opines that this view elides the "rights" basis for privacy breaches because it's property-based. Well, this is the question. What can we effectively achieve with our clauses and other tools? If agreements/contracts are the basis for what can be achieved between/among a resource owner and other parties, what are all the choices for legal theories? Tim is proposing a licensing basis. (We discussed this back in 2017-04-15 <http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note…> and seemed to reject this, but what are other alternatives?) There is a governance function and also an economic function. Looking at Sec 2.1 of the EDPS opinion on digital content <https://edps.europa.eu/sites/edp/files/publication/17-03-14_opinion_digital…>, John points to some commentary on the VRM list where someone was troubled by the "market for personal data". The point they were making was that someone could agree to selling organs (or their body into slavery or whatever), but this shouldn't perhaps be possible with selling data. We in UMA take a different, more empowered/powerful, position. Tim's Chart 1 is more of a windup to chart 2, and he will supply more explanatory text for it. The "Communicative Behavior" column means how the requirements for Value, Meaning, and Information are conveyed/communicated, e.g., trust frameworks, regulations, configuration documents, API documentation, etc. Both are about the relationships formed, and are explicitly not about "data ownership". Chart 2 is the "money chart". (Eve screenshared them, and Tim will be revising these and making them available to all before next week's meeting.) So can we state the following? - The data subject has rights over the information about them. - True as part of the Universal Declaration of Human Rights. - Different jurisdictions ensconce this right to different degrees in law/regulation or not. - True of information even prior to its being digitized. - The data controller and the data processor have property rights related to records containing a data subject's information. - The records could be in digital form or not. - The formal "interface" (communicative behavior) defined between data controllers, data processors, and data subjects is regulations. - UMA has the potential to enable data subjects ("resource subjects") and their proxies (resource owners), or even data subjects on their own, to consent to data ("resource") access by third parties ("requesting parties") in such a way that the third party is a data processor. - We believe the regulations are currently blind to: - The proxying opportunity in UMA - The potential ability for UMA to distinguish between granting access to someone who fills the role of a "data processor" vs. "another data controller" - UMA only has soft technical constraints (the "Adrian clause") around jurisdictional nonfunctional requirements for things like data localization. - The potential extension for "cascading authorization servers" would provide a potential hard technical solution. - We have the potential for providing legal toolkits that give legal solutions that may suffice. Do we need a Resource Regulator role? If you're interested, there is a SAMHSA Consent2Share webinar on April 25 at 3:30pm ET. Registration link is here <https://attendee.gotowebinar.com/register/2571416131011406338>. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

3 6

Draft minutes of UMA telecon 2017-04-27 (see new spec links below)
by Eve Maler 27 Apr '17

27 Apr '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-04-27 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2017-03-09 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-03-09> and UMA telecon 2017-04-20 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-04-20> : APPROVED by unanimous consent. Logistics Who is traveling next week, particularly next Thursday, and can't make a WG call? Justin and Mike. Mike's got Yuriy reviewing the specs and starting UMA2 implementation right now. Eve's team is also starting implementation. There is also the IIW "coming-out party" sort of opportunity for the refactored specs, to get feedback. Assuming we gain directional consensus on the refactoring today, let's schedule a special WG meeting for Friday May 12 at 9am PT/11am CT/5pm UK for the purpose of approving Draft Recommendations for a Public Comment period. The idea would be to gather feedback between now and then, particularly implementation feedback, and put it into editors' drafts timely. UMA V2.0 work Wrt the refactoring proposition, there are two big questions: - Do the specs taken together have within them everything that was important in Core and RReg (no important testable assertions missing)? - Is the handoff between the specs correct and does it not drop anything on the floor? Eve explained how the concept of permissions is handled in the Grant spec; this will be a key point for implementers and readers to test. In fact, issue #306 <https://github.com/KantaraInitiative/wg-uma/issues/306> is directly related to questions about permissions and resource-specific scopes, so please keep this in mind. For #307 <https://github.com/KantaraInitiative/wg-uma/issues/307>*,* you'd need a standards-track IETF spec to do a real IANA registry. Maybe we should at least take a registry template-like approach. The FedAuthz spec only extends Grant; it is not generally applicable to all OAuth grants. (Maybe seeing it will inspire someone(s) to work on a more generic federated authorization approach together...) So this is a backing-off of the question in #290 <https://github.com/KantaraInitiative/wg-uma/issues/290>! What is the correct description of these specs? What is "feature" and what is "benefit"? Justin called it "uma-ticket" because the permission ticket pattern is the essential feature of the grant. "User-managed access" has been the defining phrase for the set of benefits we targeted with our design principles. The file name/spec identifier should definitely have the word "grant" in it. So replace "ticket" with "grant"? That seems to be the thing to do. The "Adrian clause", about the RS getting to apply its own authorization controls, now sits in FedAuthz. Why? It only makes sense when you enter the land of federated authorization, when the RS and AS are actually operated by different parties. Consensus on continuing with the refactoring approach. *AI*: Eve: Cancel next week's meeting and move the meeting of two weeks from now. (DONE) *AI:* Eve: Reach out to George about his UMA 101 session. (DONE) *AI:* Eve: Edit specs so that it's oauth-uma-grant and an xref of "UMAGrant". (DONE - Grant rev 02 <https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-02.html> and FedAuthz rev 02 <https://docs.kantarainitiative.org/uma/ed/oauth-uma-federated-authz-2.0-02.…> ) *AI:* All: Review and implement specs, and submit issues ASAP so we'll be in a position to get the Public Comment period under way in mid-May. Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Andi 3. Eve 4. Mike 5. Cigdem Non-voting participants: - Justin Regrets: - John - Sal *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2017-04-27 / new drafts...please review ASAP!
by Eve Maler 27 Apr '17

27 Apr '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-04-27 Date and Time - *Thursdays, 9-10am PT* - Screenshare and dial-in: http://join.me/findthomas - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2017-03-09 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-03-09> and UMA telecon 2017-04-20 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-04-20> - Logistics/timing: - Need to decide on direction and Draft Recommendation schedule ASAP - Meet next week, or no because of IIW? - Get the word out about IIW sessions (including George's UMA 101 session Day 1 2-3pm!) - UMA V2.0 work: - All GitHub issues for V2.0 <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…>/ dynamic swimlane <http://www.websequencediagrams.com/files/render?link=Pu0sP0Oe2kjKc2WgdKZd> (not updated to the spec refactor) - *Please review: Grant rev 01 <https://docs.kantarainitiative.org/uma/ed/oauth-uma-ticket-2.0-01.html>** and FedAuthz rev 01 <https://docs.kantarainitiative.org/uma/ed/oauth-uma-federated-authz-2.0-01.…>* - Issues still open but that have an implemented solution in the current specs (so yell if you don't like the solutions): - *#303 <https://github.com/KantaraInitiative/wg-uma/issues/303>*: JSON Usage and OIDC for client authentication are gone in Grant security considerations - *#304 <https://github.com/KantaraInitiative/wg-uma/issues/304>*: invalid_request is gone (if anything, would only apply to protection API/FedAuthz) - *#305 <https://github.com/KantaraInitiative/wg-uma/issues/305>*: lots of metadata/discovery document cleanup and OAuth alignment, after discussion with Justin, Cigdem, Andi (let's review on the call) - Newer issues arising from the spec refactor (*#290 <https://github.com/KantaraInitiative/wg-uma/issues/290>* / *#296 <https://github.com/KantaraInitiative/wg-uma/issues/296>*) effort: - *#306 <https://github.com/KantaraInitiative/wg-uma/issues/306>*: Re-examine if downscoping should still be undefined in Grant now - *#307 <https://github.com/KantaraInitiative/wg-uma/issues/307>*: Redo Profiles section in Grant into IANA-like registry? - Generally review and decide on spec refactor - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

New issue: #305: Even more metadata fields to remove if they're in OAuth/OIDC Discovery?
by Eve Maler 26 Apr '17

26 Apr '17

https://github.com/KantaraInitiative/wg-uma/issues/305 In the continuing quest for simplification and OAuth/OIDC alignment as I work on the refactored specs, this seems like a biggie. Thoughts from y'all? If we go with Grant/Fed Authz vs Core/RReg, which seems to be the prevailing opinion, I really don't like the idea of including all the "here's a new definition of how you do discovery/metadata infrastructure" stuff in our specs vs. just leveraging OAuth's and OIDC's invitation to add new metadata fields. The only unattractive part is that OAuth discovery is in draft, and I wonder if it's going anywhere. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 1

Pre-session ad hoc on Wed 9am PT/5pm UK; big decisions on Thursday
by Eve Maler 25 Apr '17

25 Apr '17

Andi, Cigdem, and I are going to meet tomorrow, Wednesday, at 9am PT/5pm UK to review the refactored specs. You are very welcome indeed to join us, but you *MUST* let me know ahead of time (i.e. *NOW*); right now we're just planning to meet on Skype. On Thursday, we need to make a key decision on the refactoring direction, remaining open issues, and our timeline. So far the response has been positive on the grant spec; we need to be just as certain about the federated authorization spec (which is currently in an inconsistent state, but I'll send out a link before Thursday's call). *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2017-04-20
by Eve Maler 21 Apr '17

21 Apr '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-04-20 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2017-03-09 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-03-09>: Deferred. UMA V2.0 work *#293 <https://github.com/KantaraInitiative/wg-uma/issues/293>*: Consensus on pushing only a single claim token being "hunky dory" (a good idea). *#298 <https://github.com/KantaraInitiative/wg-uma/issues/298>*: The redirect-back paths look much cleaner now. *#290 <https://github.com/KantaraInitiative/wg-uma/issues/290>* (Generality of RReg spec?) and *#296 <https://github.com/KantaraInitiative/wg-uma/issues/296>* (Out-of-the-box profiling for tight AS-RS coupling): We looked at the new oauth-uma-ticket rev 00 <https://docs.kantarainitiative.org/uma/ed/oauth-uma-ticket-2.0-00.html> experimental spec. General support for this approach, though we don't have a federated authorization spec yet. Can we sync the high-level flow diagram more with OAuth's abstract protocol flow diagram? Andi says: "I like this effort to re-architect the way the specs are laid out, Eve. Happy to help if I can (dm me later if so and we can discuss)." Cigdem says: "I think if we want to provide a comparison to OAuth - comparison via "abstract protocol flows" maybe more appropriate. In this case (C) Authorization grant: includes ticket, claims collection, RqP interaction etc. for UMA, After that we can have the more detailed flow diagram." So we could have two diagrams, where the first indicates explicitly the mapping to OAuth's letters A through F. Why do we still have registration_endpoint metadata? Sort of historical (because our group wrote the first dynamic client registration spec)? Should we consider dropping it? People could just use the OIDC spec, or the draft OAuth metadata spec, to declare their registration endpoint. Eve will make an issue to consider this. (DONE <https://github.com/KantaraInitiative/wg-uma/issues/305>.) Ishan points to the OIDC wording: "Additional Client Metadata parameters MAY also be used. Some are defined by other specifications, such as OpenID Connect Session Management 1.0 [OpenID.Session]" Since we've never had an "UMA grant" per se before, should we overtly label this as UMA2? Seems to make sense since UMA1 is out there (and we have semantic versioning!). Eve has done so, sort of, but will make it more obvious. "Permission" has been defined, but is there actually any reason to do so? It doesn't seem like it. In the spec swimlane, the redirect and redirect-back, there should probably be two arrows/steps, since there are two whole sections for this. This is only a "sample high-level flow" in that there are pushed claims followed by interactive claims gathering followed by success. The client approaching the resource first, with the whole ticket flow etc., is not optional. The swimlane should use very short phrases with a list following, a la 6749's style. Sec 1.3.2's claims collection discussion should clarify that while claims collection is probably not really optional, claims don't strictly have to be collected through UMA messaging; it could be done out of band (don't use that phrase?). In the section on Endpoints, the last paragraph may be out of place. *AI:* Eve: Propose an ad hoc early next week for at least her, Andi, and Cigdem (others welcome) to work on the refactored specs. Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Sal 3. Andi 4. Eve Non-voting participants: - Ishan - John - Crina Regrets: - Justin - Maciej - Mike *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

UMA Legal: meeting tomorrow 8am PT to discuss deliverable #2 topics
by Eve Maler 20 Apr '17

20 Apr '17

<eom/> *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft UMA grant spec for your perusal
by Eve Maler 20 Apr '17

20 Apr '17

https://docs.kantarainitiative.org/uma/ed/oauth-uma-ticket-2.0-00.html I *might* get time to do at least a partial federated authorization spec tomorrow early morning -- we'll see. Please weigh in here if you manage to get time to skim it before the call. (In the course of working on this spec, I ruthlessly chopped out lots of duplicative text, partly because one purpose was to get things more readable and partly because the spec was getting short enough that the main sections were ending up next to each other in most cases, with little need to do cross-references to make sense of the three-party "dance" through links. But I think quite a few of the edits could be back-ported to the existing specs, if we ultimately don't like the refactoring idea. I'm keeping track of a few key editorial things I want to do regardless even of this back-porting notion.) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0