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

No Legal call tomorrow
by Eve Maler 18 May '17

18 May '17

Instead, I'm going to do some offline doc review with Tim. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Do Promises To Use "Best Efforts" To Protect Data Really Require Unreasonable Action? - Data Protection Report
by John Wunderlich 18 May '17

18 May '17

In UMA legal and the Information Sharing workgroups, it will be important to be mindful of 'best practices' vs 'reasonable efforts'. http://www.dataprotectionreport.com/2017/05/do-promises-to-use-best-efforts… -- 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

Draft minutes of UMA telecon 2017-05-18
by Eve Maler 18 May '17

18 May '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-05-18 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2017-04-27 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-04-27>: APPROVED by acclamation. Logistics - 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 We reviewed the recommendations of UMA telecon 2017-05-12 and everything seemed to be acceptable. We have consensus. Issue #312 <https://github.com/KantaraInitiative/wg-uma/issues/312>: Consensus to remove the language (option 2). Issue #313 <https://github.com/KantaraInitiative/wg-uma/issues/313>: Copy the text instead of move it. The second paragraph is not entirely relevant to Grant, so only a subset should be copied over. Issue #314 <https://github.com/KantaraInitiative/wg-uma/issues/314>: The RS, along with the AS, has to manage mappings of resource IDs to specific resource owners. Let's drop the note. Issue #315 <https://github.com/KantaraInitiative/wg-uma/issues/315>: Eve has suggested wording. This is practically editorial. We should say "pre-registered" instead of "registered". Should we say first "Only if the client has pre-registered a single full claims redirection URI, this is OPTIONAL." and then put the other proposed wording at the end? Yes. Issue #317 <https://github.com/KantaraInitiative/wg-uma/issues/317>: Did Justin mean "also non-null", or did he mean "also null"? Gluu first gets a token with no scopes, and then adds scopes to it. Is that first token a true RPT? It doesn't have permissions associated with it, so this could be a sort of interim step. It's certainly okay for a client not to pre-register for/request scopes. And we decided that it's okay for the RS to include zero scopes in its permission ticket. (Justin had made a separate comment about some inconsistency in FedAuthz about our language on this point.) So if we were serious about allowing zero scopes in *RequestedScopes*, then if that is null too, then it should be possible to issue a token with "nothing – that's what you wanted, and you'll like it!" But if it was non-null, that should result in a hard error. So we need to break this out into two bullets, with the two different conditions. Or the more elegant solution is to remove "is non-null" from the current last bullet, because if CandidateGrantedScopes is null and RequestedScopes is non-null, then the former is < the latter, and it would come under the third bullet. There should be only two logical bullets: = and <. Issue #322 <https://github.com/KantaraInitiative/wg-uma/issues/322>: We made a strong decision to make permissions be a SHOULD for extensibility reasons, in case someone wanted to experiment with the dividing line between AS and RS responsibilities. However, token introspection is already optional in OAuth, and with the spec refactoring, maybe this isn't necessary anymore. And changing from a SHOULD to a MUST is backwards incompatible, whereas the reverse isn't (it would break implementations to change it in this direction). Consensus to change to a MUST. Issue #320 <https://github.com/KantaraInitiative/wg-uma/issues/320>: We don't understand this one. Hopefully this will result in only non-normative language later. Issue #321 <https://github.com/KantaraInitiative/wg-uma/issues/321>: Simple fix. Issue #318 <https://github.com/KantaraInitiative/wg-uma/issues/318>: This is a normative change, but we should do it for consistency. (This also changes the WSD.) Issue #316 <https://github.com/KantaraInitiative/wg-uma/issues/316>: Eve will work with Justin to ensure it says everything he wants, in addition to reiterating any OAuth messages as appropriate. Mike also notes that FAPI from OIDC went beyond requiring state (but of course that is an industry profile). Attend to: Issues #319 <https://github.com/KantaraInitiative/wg-uma/issues/319> and #323 <https://github.com/KantaraInitiative/wg-uma/issues/323> and the following editorial instruction: - Remove "Note:" from beginnings of "For an example of how..." references. A candidate motion: MOTION: Mike moves and Maciej seconds: Approve the draft UMA 2.0 specifications, Grant rev 04 and FedAuthz rev 04, as amended according to the instructions of UMA telecon 2017-05-18, as Draft Recommendations for public comment and IPR review. APPROVED by unanimous consent. *AI:* Eve, Justin, and Maciej: Edit! and ensure the Draft Recommendation markers are properly in place. *AI:* Eve: Work with Kantara staff on review/publication next steps. Logistics Note that, once this 45-day review has begun, any substantive (think backwards-incompatible) changes will require going back to another such review. We should review the 05 drafts ASAP to catch any text implementation boo-boos before this goes out the door – even before next Thursday. Maybe we can also figure out #320 before publication as well. Let's try to make hay early next week while the sun shines. Maybe Eve will even call an ad hoc. We can figure out our meeting schedule after that. Note: No meeting the week of CIS (June 22). 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. Maciej 5. Eve 6. Mike 7. Cigdem Non-voting participants: - James - Jin Guest: - Jim Willeke Regrets: - John W - Justin *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

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