- WG-UMA - mailman.kantarainitiative.org

Notes from UMA Legal telecon 2017-05-12
by Eve Maler 12 May '17

12 May '17

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2017-05-12 - Reviewing draft deliverable #3 – which is now a proposal paper! Attending: Eve, Tim, John (the koala), Mark Tim showed us his nearly-ready latest deliverable. It's sort of deliverable #2, but it also looks a bit like a full-blown #3 because it's a proposal for a legal framework. Elevator pitch: The User-Managed Access (UMA) technical protocol applies protection policies to permission tokens. The UMA legal framework maps those permission tokens to licenses as legal devices. This licensing mechanism is valuable to individuals, organizations, legal professionals, and privacy professionals because it allows Alice to license Bob to use her digital resources on her terms. What do we do about the technical terms that we get from OAuth, "authorization grant", "authorization", "access" (which is colloquial, Eve believes), etc., and the legal (usually, because of regulations) term "consent"? Then there's "permission", "approval", etc. "Grant" comes from OAuth but is also, a verb, pretty neutral. The usual formulation in most regulations is "notice and consent" as a workflow. Mark observes that "consent to authorize (access)" could be a viable way of seeing how regulators see it. John calls UMA "an affirmative action to allow access". Eve cautions that UMA does not *prescribe*a user experience, and it *might not* involve an affirmative action. Would establishment of a default policy, by an AS and not by an RO, count? That sounds like an opt-out flow. Eve runs through the Open Banking interpretation of consent and authorization. (See this blog post <https://www.forgerock.com/blog/open-banking-is-nearly-here-and-it-is-going-…>.) PSD2 has terminology <https://www.starlingbank.com/explaining-psd2-without-tlas-tough/> like this, mapped to OAuth/OIDC overlays: - ASPSP is, roughly, the bank (it acts as the AS/RS – in OAuth/OIDC they're in the same domain) - AISP (Account Information Service Provider) is like Mint - PISP (Payment Initiation Service Provider) is like Amazon, selling you something - TPP (Third Party Provider) is a client app fronting one of the last two guys - PSU (Payment Services User) is the resource owner What they require for consent is that the PSU must "give consent" to the TPP (client), not the ASPSP (authorization server). This happens in a fairly complex dance that happens over two stages, concluding in an authorization code flow. So this sounds an awful lot like Mark's formulation. [image: (smile)] BTW, the OAuth spec slipped up and accidentally used the word "consent" once <https://tools.ietf.org/html/rfc6749#section-10.12>. It's a goal to make sure regulators, policymakers, and deployers can get comfortable with the notion that UMA deployments can meet "consent" requirements (as long as user experience requirements are likewise met). UX is outside the scope of the pure technical layer, but the mappings we do here can surely remark on UX where we see fit. Tim plans to finish working on the paper over the weekend. Eve will upload it as soon as she can. Mark is doing mapping exercises in CIS WG; we should liaise on that. Also, note that the BSC DG has put in a recommendation for Kantara to consider an org-wide Legal WG, since this work is going on all over the place! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 2

Notes from UMA telecon 2017-05-12
by Eve Maler 12 May '17

12 May '17

MinutesRoll call Quorum was not reached. Approve minutes Approve minutes of UMA telecon 2017-04-27 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-04-27> : Deferred. Logistics - Can we dispose of current issues and pass a motion to move to public comment and IPR review period today? - Potentially recommend actions on issues, but likely not pass a motion. [image: (smile)] We could do an e-ballot, which takes (we think) 7 calendar days. Eve will take it under advisement. Note that Justin (a non-voting participant) can't make next Thursday's call. - If so, what to do in the interim WG-wise? - We should be able to meet regularly until CIS week (which we'll cancel for sure), unless we decide to skip some meetings after a hopefully successful vote to start the big review. UMA V2.0 work - Note: How the resource server validates the RPT is outside the scope of this specification, but it may be useful to consult [UMAFedAuthz].#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. - *Instructions*: Let's close the issue. - #304 <https://github.com/KantaraInitiative/wg-uma/issues/304>: Do we need the invalid_request issue (that is, error)? 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. - *Instructions*: None of us could think of a reason to need it, and it's already gone. Close the issue. - #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. - 6749 is actually more subtle about constraining what the client can ask for <https://tools.ietf.org/html/rfc6749#section-6> in terms of downscoping, and maybe we can make use of this. If the scope parameter is left off, we should state that "If the client does not include the scope parameter, then the refreshed RPT has the same permissions as the original RPT." But is this right? What if some expired since then? Should there be a reevaluation? This is the question of the simple authorization decision model of OAuth and the more complex policy decision model of UMA; when should policy decision-making happen? E.g., before issuing refresh tokens (that is, when issuing the original access token)? When between presented with a refresh token and being asked for a freshened-up access token? Remember that refresh tokens themselves should have appropriate TTL periods, and maybe the refresh token should die if the RPT would be useless later. - In *Grant Sec 3.6*: "If the client includes the scope parameter in its request, the authorization server MAY limit the scopes in the resulting permissions to those requested by the client." In other words, if the client mentioned scope A, and the original RPT had scope A on resource 1, then the new RPT will leave out resources 2, 3, and 4 that didn't have scope A on it. Yes, the client could hurt itself, but whaddya gonna do? The whole point of refresh is that you can ask for less, but without the user (RO in the case of other grants and RqP in the case of UMA) involved, you can't ask for more. - In *Grant Sec 3.3.5*, after "This is because RPTs are associated with scopes that are associated with specific resources." say "Note: The outcome of authorization assessment may result in expiration periods for RPTs, permissions, and refresh tokens that can affect the client's later requests for refreshing the RPT." - In *Grant Sec 3.6*, add "The authorization server MUST NOT treat the client's request to refresh an RPT as if it were a request for a new RPT requiring an authorization assessment calculation." - Instructions: - *Grant Sec 3.1*: Instead of "Note: How the resource server arranges for resources to be protected in the context of a resource owner is outside the scope of this specification, but it may be useful to consult [UMAFedAuthz]." say "For an example of how the resource server can put resources under the protection of an authorization server, see UMAFedAuthz." - *Grant Sec 3.2.1*: Instead of "Note: How the resource server arranges to obtain the permission ticket from the authorization server is outside the scope of this specification, but it may be useful to consult [UMAFedAuthz]." say "For an example of how the resource server can obtain the permission ticket, see UMAFedAuthz." - *Grant Sec 3.3.4*: Instead of "Note: [UMAFedAuthz] describes how the resource server MAY obtain the permission ticket from the authorization server." say "For an example of how the resource server can obtain the permission ticket, see UMAFedAuthz." - *Grant Sec 3.5*: Remove both "Note: How the resource server validates the RPT is outside the scope of this specification, but it may be useful to consult..." and "Note: [UMAFedAuthz] describes how the resource server MAY introspect the token at the authorization server preparatory to responding to the client's request." and replace with... - #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? - What few items could we get away with? And if there's a huge profile or extension vs. individual items, do we need a registry approach? Actually, the URI as the identifier and the plea to put it into our discovery document are the most important part. We can probably trash the rest. - *Instructions*: Write it up as a simpler recommendation to provide a URI, with advice. - #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. - Eve (lightly), Justin, and James are in favor. Sarah's and Justin's original proposal kind of went in this direction already. - *Instructions*: Let's do it. - *#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...) - Justin and James had weighed in to keep this as is. This has security implications. Mike is okay with keeping it as is. Justin notes that clients are not OAuth-generic; only libraries. Cigdem agrees. - *Instructions*: Let's close without action. - *#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? - *Instructions*: Let's remove. We also have to add something saying "The PAT is an OAuth token and, as such, is susceptible to OAuth threats." - Is there anything unique not already covered in 6749 or the Threat Model doc we should submit? Maybe not. *AI:* Eve: Implement editor's instructions, send out revs 04, and update all the relevant issues. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

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

Don't trust OAUTH?
by John Wunderlich 08 May '17

08 May '17

See https://arstechnica.com/security/2017/05/dont-trust-oauth-why-the-google-do… Does UMA get caught in this blast? John Wunderlich, BA, MBA IAPP Fellow of Information Privacy CISA, CIPM, CIPP/C, PbD Ambassador @PrivacyCDN <https://twitter.com/PrivacyCDN> & Privacist -- 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.

3 3

Hundreds of thousands of kids have identity info hacked from pediatricians’ offices
by John Wunderlich 05 May '17

05 May '17

https://www.databreaches.net/hundreds-of-thousands-of-kids-have-identity-in… -- 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

Chinese Government Releases Overreaching Draft Regulations on Cross-Border Data Transfer
by John Wunderlich 05 May '17

05 May '17

The Resource Regulator in action: http://www.dwt.com/Chinese-Government-Released-Overreaching-Draft-Regulatio… -- 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 that the WG call tomorrow has been canceled due to IIW
by Eve Maler 03 May '17

03 May '17

(We are having a Legal call on Friday!) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Browser Clients in UMA?
by Mike Schwartz 01 May '17

01 May '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