- WG-UMA - mailman.kantarainitiative.org

Agenda for UMA telecon 2017-05-18 (looking for quorum for this meeting!)
by Eve Maler 17 May '17

17 May '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-05-18 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-04-27 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-04-27> - Logistics/timing: - Candidate motion for consideration: - "Approve the draft UMA 2.0 specifications [as amended according to the instructions of UMA telecon 2017-05-18] as Draft Recommendations for public comment and IPR review." - Assuming we approve and forward the specs today, how to structure the next 45 days' worth of time? - 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) - *Grant rev 03 <https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-03.html>** and FedAuthz rev 03 <https://docs.kantarainitiative.org/uma/ed/oauth-uma-federated-authz-2.0-03.…>*; stay tuned for revs 04 shortly - See UMA telecon 2017-05-12 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-05-12> for detailed notes about issue-closing recommendations, spec wording proposals (to appear in revs 04), and issues already closed - Revs 04 may also contain some editorial changes to intro sections - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 1

An Algorithm Summarizes Lengthy Text Surprisingly Well
by John Wunderlich 15 May '17

15 May '17

https://www.technologyreview.com/s/607828/an-algorithm-summarizes-lengthy-t… -- 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

Anyone in UMA WG going to K(NO)W Identity in DC
by Thomas Hardjono 14 May '17

14 May '17

Anyone in UMA WG going to K(NO)W Identity in DC this coming week? /thomas/

1 0

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