April 2017 - WG-UMA - mailman.kantarainitiative.org

Open issues - let's try to work through them by email BEFORE May 12
by Eve Maler 10 May '17

10 May '17

We really don't have a lot of 2.0 issues <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…> left. A few new ones are coming to light now...which is good. The sooner the better. :) BTW, I've just published Grant 03 <https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-03.html> and FedAuthz 03 <https://docs.kantarainitiative.org/uma/ed/oauth-uma-federated-authz-2.0-03.…>, with a bunch of strictly editorial cleanup. Current status: - #303 <https://github.com/KantaraInitiative/wg-uma/issues/303>: JSON usage and OIDC for client authentnication: These security considerations have been removed from the drafts, and it doesn't seem they'd be missed. Unless anyone yells, we'll close this issue for May 12. - #304 <https://github.com/KantaraInitiative/wg-uma/issues/304>: Do we need the invalid_request issue? It would only be for FedAuthz (the protection API). I've taken it out for now. Request messages have their own custom errors for specific things that could go wrong. Basically, yell if you see a need to add it (or any other more-specific errors) back, or we'll close this with no action by May 12. - #306 <https://github.com/KantaraInitiative/wg-uma/issues/306>: Best to keep downscoping undefined when refreshing? I've now included a rationale in the refreshing language in Grant. Given the current state of Grant and FedAuthz, let's plan to close this without action by May 12 unless someone has a problem. - #307 <https://github.com/KantaraInitiative/wg-uma/issues/307>: Lower-priority, but nice to think about since there are already a bunch of profiles and extensions: Should we create a "pseudo-IANA-registry" for profiles and extensions? - #308 <https://github.com/KantaraInitiative/wg-uma/issues/308>: Really kind of low-priority: Should we flatten the innards of need_info to remove the error_details layer? If no one pays attention to this before May 12, let's close without action. - *#310* <https://github.com/KantaraInitiative/wg-uma/issues/310>: NEW and important, highlighted by Mike: Our requirement to have the client pre-register for scopes is likely at least somewhat problematic. See the issue for why. (Domenico, this would potentially affect your Venn...) - *#311* <https://github.com/KantaraInitiative/wg-uma/issues/311>: NEW and would be nice to look at: We go on and on about how the PAT is susceptible to implicit grant threats, but this seems like just a generic OAuth threat (especially with our refactoring now), and everyone is familiar with it. Remove? Please review, and in particular please weigh in on 310, 311, and any other new issues that get submitted between now and our May 12 meeting. Thank you! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 1

Browser Clients in UMA?
by Mike Schwartz 30 Apr '17

30 Apr '17

In UMA Grant, any thoughts about including considerations for browser based clients with regard to RPT, PCT and refresh tokens? - Mike

2 1

Re: [WG-UMA] PSD2 as a driver for UMA
by James Hazard 30 Apr '17

30 Apr '17

Kevin, thanks. If I've understood your concern, it is that hosting of the data stores should be independent of financial institutions. My thought is that the data model should work for both (all) situations - the data store can be hosted by a financial institution or by someone else, including by individuals themselves. This, I believe, is how email works - there is a common standard and you can set up your own server for yourself or a group, or have someone else do it. The email interchange standards and open source software keeps this cheap and portable. You can take your email history when you change hosts, so hosts have little leverage. The critical thing seems to be the data model and interchange protocols. Jim On Sun, Apr 30, 2017 at 3:48 AM, Kevin Cox <kevin(a)welcomer.me> wrote: > This is a good start but there are better ways of handling money. > > We do not need AISP (Account Information Service Provider) or PISP > (Payment Initiation Service Provider) any more than we need Identity > Providers. What we need are free apps we are given to look after the > information in our accounts, and for apps to help us to spend our money as > we see fit. We do not need Identity Providers as we are quite capable of > acting on our own behalf and purchasing the tools that enable us to do it > electronically. The apps are free and we use the transaction charges made > on transfer of money to pay for the app development. These transfer > charges will be less than the current transfer charges. > > The cost of operating electronic systems will drop when we get rid of > intermediaries in electronic space that stand between people and between > people and collaborative human entities like companies and governments. We > replace the intermediaries with open source apps. > > Money is the good one to start with because the way we organise our money > system is ridiculously expensive. The savings made with money can fund the > development of other ways of working together in collaborative and > co-operative ways. > > Money is a promise to repay. A promise costs nothing to make. It costs a > lot when the promise is broken and not fulfilled. A promise is zero cost > so why do we charge for the use of zero cost money tokens that represent > the promise? We should not pay to use money tokens. We should pay if we > break a promise. Changing to zero cost money tokens will reduce the cost > of operating an economy by at least 50% and perhaps more. We have become > so used to thinking that money tokens have a value that we forget that cash > tokens have no value. The value is the promise that the government will > accept the money for us to pay our taxes. The idea that money tokens have > to have a value leads to the planned inflation of money tokens, nonsense > cost-benefit studies that rarely predict outcomes, expensive cumbersome > systems like collateralized debt and bitcoin - and these are only the least > harmful. > > We can be truly autonomous in the electronic world but only if we have > electronic ways of working together in small and large collaborative groups > that can handle the situations when some of us break our promises. > > Here is a proposal > <https://medium.com/@kevin_34708/water-rewards-information-rich-money-345ee9…> we > are working on to save the community of 400,000 people in which I live $70M > per year for no cost to the community. An emergent property of the system > will be a safe secure electronic identity for our Co-op members that only > they can access. (PS. It is the reason I am not at IIW) > > Kevin > > > On Sun, Apr 30, 2017 at 1:44 AM, James Hazard <james.g.hazard(a)gmail.com> > wrote: > >> Agreed. PSD2 and GDPR both require P2P data model. Mentioned here in >> conversation with Eve. https://commonaccord.wordpress >> .com/2017/04/09/prose-objects-for-enterprise/. >> >> A P2P, smart contract and prose object data model for finance could look >> something like: >> http://www.commonaccord.org/index.php?action=doc&file=bqc/fr >> /bnpp/a5we/Account/Check/00001/06-Accept.md >> >> On Sat, Apr 29, 2017 at 5:38 PM, Adrian Gropper <agropper(a)healthurl.com> >> wrote: >> >>> https://www.evry.com/en/news/articles/psd2-the-directive-tha >>> t-will-change-banking-as-we-know-it/ >>> >>> >>> >>> -- >>> >>> Adrian Gropper MD >>> >>> PROTECT YOUR FUTURE - RESTORE Health Privacy! >>> HELP us fight for the right to control personal health data. >>> DONATE: http://patientprivacyrights.org/donate-2/ >>> >>> _______________________________________________ >>> WG-UMA mailing list >>> WG-UMA(a)kantarainitiative.org >>> http://kantarainitiative.org/mailman/listinfo/wg-uma >>> >>> >> >> >> -- >> @commonaccord >> >> _______________________________________________ >> WG-UMA mailing list >> WG-UMA(a)kantarainitiative.org >> http://kantarainitiative.org/mailman/listinfo/wg-uma >> >> > > > -- > 0413961090 > -- @commonaccord

3 2

PSD2 as a driver for UMA
by Adrian Gropper 29 Apr '17

29 Apr '17

https://www.evry.com/en/news/articles/psd2-the-directive-that-will-change-b… -- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

2 1

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