- WG-UMA - mailman.kantarainitiative.org

Preparing for our call today - hope you can make it
by Eve Maler 14 Dec '17

14 Dec '17

If you haven't yet read the latter half of the "URGENT: The UMA 2.0 specifications are now in Kantara All-Member Ballot" thread <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/jL3puNyiF…> where Nat raised an issue to do with the OAuth Mix-Up attack, please take a moment to do so before the call shortly. He has already attached similar feedback to his vote (a No vote) on the ballot, and made some specific recommendations for next actions). I'm very grateful to Nat for his comments! His application of time and expertise are always welcome. Although Kantara process does not require us to provide a disposition of comments at this stage of the proceedings, the nature of Nat's first comment particularly seems to warrant such. I've discussed the issue a bit with Justin, and right now, it's our current mutual understanding that the OAuth Mix-Up attack does *not* apply to UMA. I'll try to explain the logic briefly here, and plan to explore this in the call (and, as warranted, in continuing fashion with the WG) to ensure we get a proper understanding and consensus around this issue. Helpful resources: - https://tools.ietf.org/html/draft-ietf-oauth-security-topics-04#section-4.4 - https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-01 The theory of why the attack (a client-AS MITM attack that exploits an endpoint discovery problem) applies is that the OAuth redirect_uri parameter, which the client gives to the AS to enable the AS to send the user (resource owner) back to the client after the process at the authorization endpoint is done, is directly analogous to UMA's claims_redirect_uri. However, UMA already has built-in ways to provision the client with the targeted AS and endpoint information it needs to make good endpoint-routing decisions, before the client gets to the stage of having to give the AS a claims_redirect_uri value. The first step is that the RS knows which AS is protecting whichever resource the client is trying to request, and it provides an as_loc value ("AS location"). This gets the client to the AS discovery document, where the client finds at least the token endpoint URI. (UMA doesn't have an authorization endpoint.) If the client gets an error from this endpoint that leads it to do interactive claims gathering, and it didn't yet know the claims interaction endpoint from the discovery document, it would get it from the need_info error response (the redirect_user hint) from that token endpoint. If, by chance, the client is supposed to send the requesting party to do interactive claims gathering first before approaching the token endpoint, this relies on the claims interaction endpoint also having been declared statically in the discovery document. I hope this helps us sort through the issue. Hope you can join the call. Thanks. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2017-12-14
by Eve Maler 12 Dec '17

12 Dec '17

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-12-14 Date and Time - *Thursdays 9am 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-11-30 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-11-16> - Discuss ballot results, comments, and next steps - See discussion in the latter part of the thread here <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/jL3puNyiF…> - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

URGENT: The UMA 2.0 specifications are now in Kantara All-Member Ballot
by Eve Maler 11 Dec '17

11 Dec '17

I'm pleased to report that the Draft Recommendations, which our WG approved to progress to the LC, and which the LC certified in a very efficient amount of time, have been put into All-Member Ballot by Kantara staff in a likewise extremely efficient manner. Special thanks to Andrew Hughes and Megan Cannon for their assistance! I have prepared a Get Out The vote (GOTV) Google spreadsheet <https://docs.google.com/a/meshfire.com/spreadsheets/d/1FpiB6PMH9Tx4nbn3PYuM…> to help us reach out to Kantara members and member reps individually, to make the best use of this two-week balloting period. It will go by FAST. I invite you all to please help by going into the spreadsheet (I will share with any WG participant who requests access), filling in Kantara member/rep names, and -- especially -- *marking yourself down as a "champion" to reach out personally to ask these people ASAP to vote YES on the ballot*. There are tabs in the spreadsheet that even suggest email template text to make things extra easy. ;) By the way, several Kantara individual members are also UMA WG participants, and I will be dropping each of you a note shortly! Thank you -- please do take action on this as soon as you can, because the ballot runs from today only until *DECEMBER 11*! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 8

Notes from UMA Legal telecon 2017-12-08
by Eve Maler 08 Dec '17

08 Dec '17

https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not… 2017-12-08 Attending: Eve, Devon, Tim, Sal, Jeff NO MEETING on *December 15* (next week). YES MEETING [image: (smile)] on *December 22* (the week after). That will be our last meeting of the year! Regarding our planning around getting the framework ready for end-of-year review, let's discuss the definitions. We should put them in the back, in an appendix, because they don't flow narratively. We should cross-refer to them from the narrative text and we could support that reference with some illustrative diagrams to help make sense out of them. The legal definitions have an RSO definition that is nearly there, but seems to be missing the connection with the RO. E.g., if you look at the definition of an RS in the Grant spec, it is "*A server that hosts resources on a resource owner's behalf* and is capable of accepting and responding to requests for protected resources." The PCT is not like an RPT; it doesn't mean "I've got access to all this stuff, so please let me in to it again", it means "I've got Bob with me again, so can I please get access to whatever stuff Bob gets access to?" Though the UMA specs avoid the word "consent" (much as the OAuth spec does except in a single, probably accidental case), this framework doc need not, and can actually advocate for the case that UMA is directly and concretely relevant to data subject consent. This is because we can make an *unbroken* chain from technical artifacts and entities to parties' delegation of authorization and permissions. Or, depending on the audience, the reverse! Do we really need an unbroken chain, or is that technical/spec thinking that isn't applicable in the legal-framework case? It's Eve's theory because of the whole "prose objects" approach, "smart contracts", and the like. We'll have to see. (Tim suggested Devon could put some thinking into that. [image: (smile)]) There is a specific use case when Alice herself acts as the RqP. In this case, the CO role is outsized because all the weight of "who Alice is sharing with" gets placed on who/what the CO is. Could the client (or Bob) require that a consent receipt be issued around the RqP-CO delegation relationship? This could be considered a best practice, as part of the UMA-CR joint work. *AI:* Tim: Revise legal definitions before inserting into the doc, to ensure they align with our latest analysis of the delegation and licensing mechanism and that the RSO definition connects with the RO in some fashion. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

We have a Legal telecon tomorrow
by Eve Maler 08 Dec '17

08 Dec '17

There are some action items from last week to review, I believe. And Tim and I created some new delegation-related diagrams we can share/insert. I am not available for a call next Friday (December 15). Are enough people available to meet on December 22 to close out 2017? Eve (sent from my iPhone, possibly with Siri's "help": +1-425-345-6756)

1 0

No WG call tomorrow / Recommendation publication
by Eve Maler 06 Dec '17

06 Dec '17

Hi folks— The ballot closes Monday and there are some efforts going on behind the scenes in anticipation of passage and publication (e.g. put together a press release). If you’re interested to offer help, please get in touch. Thanks. Eve (sent from my iPhone, possibly with Siri's "help": +1-425-345-6756)

1 0

Second call for contributions for PII handling based on user privacy preference
by n-sakimura 04 Dec '17

04 Dec '17

Hi A new call for contributions for ISO/IEC JTC 1/SC 27/WG 5 on Framework for user-centric PII handling based on privacy preference management by users was issued. The document number is WG5 N1100. It should become soon available at the liaison committee. If WG UMA has not yet done so, it might be a good idea to do so. Best, Nat Sakimura PLEASE READ :This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail.

1 0

Notes from UMA Legal telecon 2017-12-01
by Eve Maler 01 Dec '17

01 Dec '17

https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not… 2017-12-01 Attending: Eve, Kathleen, Tim, Devon, Theresa, John, Bjorn, Mark Agenda: - Review what we learned in yesterday's joint UMA/Consent Receipts call - Look at new language in Business Model Paper 5 - Figure out what we can accomplish by the end of the year In HIPAA, there's "consent directives". "Release of information", "patient right of access", and "authorization" all mean the same thing. There is no authorization required for TPO (treatment, payment, and operations). For operations, an entity has to have, or have had, some kind of relationship with the patient. A "covered entity" (a term of art) would then have "HIPAA consent" (different from regular consent, which the patient has no ability to *not* grant). There's implied and specific consent. ISO standard 17975 <https://www.iso.org/standard/61186.html>, *Health informatics -- Principles and data requirements for consent in the Collection, Use or Disclosure of personal health information*, lays this out. HITECH has now been absorbed under HIPAA. If you pay for any services completely out of pocket, then the provider must honor your "dissent" (an opt-out). "Grantor's choice" is where the provider has no choice; it's another kind of directive regarding a "right-of-access request". Can we map UMA's sweet and sour spots to these definitions of consent, for various laws and regulations? The paper needs to do this at a shallow level to be credible; the tools need to do this at a deeper level. The theory is that our framework can lighten the load of anyone building their legal/contractual/licensing layer not only through templating but also, potentially, through business process modeling. This is where a CommonAccord workflow can help as part of the tooling. *AI:* Eve: Talk to Andrew about whether our WG can get access to the ISO standard through KI's liaison relationship. *AI:* Eve: Work on legal diagrams. *AI:* Tim: Add legal definitions to the paper. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Legal call is on for tomorrow (Friday) - back to using join.me
by Eve Maler 30 Nov '17

30 Nov '17

Let's review what we learned in today's joint call, look at new language in Business Model Paper 5 that Tim has added, and figure out what we can accomplish by the end of the year. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2017-11-30
by Eve Maler 30 Nov '17

30 Nov '17

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-11-30 MinutesJoint meeting notes - Consent Receipts people present on Consent Receipts to UMA people (Eve and Domenico are the only "non-CIS WG" UMAnitarians on the call.) CR V1.0 is fully published and downloadable now. The WG has developed V1.1 and has voted to move it to the public review period. That's due to go to the 45-day review shortly. The data structure inside the receipt has seen some structural changes (to allow multiples, e.g. of data controllers), and the spec has had editorial changes. V1.1 had a fundamental goal to make no breaking changes. There were a couple of minor such changes. The spec is for a data structure, not a protocol. It has implementers in various stages, mostly for internal use and with heavy extensions (which is compatible with the "MVCR" intention – "minimum viable"). Consentua, digi.me, JLINC (when it gets to V1.0 of its product), and Open Consent Group are all implementing. There are a bunch of random commenters on GitHub. There have been a lot of downloads of V1.0, more than UMA! The informal roadmap includes what will likely be a V2.0 that focuses on interop issues. The new Consent Management WG would be able to feed best practices into the CR work at that point. The CR would be able to become something like a "personal data privacy receipt" that captures all the justifications for processing. Or maybe this is overstating future directions. - UMA people present on UMA to Consent Receipts people, including reviewing the GitHub issues labeled "shoebox" <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…> Eve showed the UMA V2.0 specs, and a quick demo of a "profile and privacy dashboard" that integrates UMA2. Mary asked who has built UMA-style sharing dashboard interfaces. ForgeRock has, and HIE of One has (on UMA1 so far). CR has focused first on the notice requirements, not all privacy requirements. By contrast, UMA's design center is more about authorization/access control made convenient for humans. So it's a control mechanism. A regulation like GDPR has made "choice and control" more important and viable for data subjects, but there are a lot of consent flows outside UMA use cases. - UMA Legal people present on UMA Legal to all Mark notes: There is no obligation in privacy law for natural persons to protect other natural persons' data. It's about organizations. Companies have used individuals as a loophole to get around their obligations. The UMA Legal plan to use licenses can plug some loopholes. Chris notes: It's not so much that people have a fear factor about sharing data, but we need to press for a unified identity+consent structure that is deregulated. Andrew proposes: A "consent receipt" is a record that should be issued whenever a person agrees to something. Can we say that Alice (the resource owner) is definitely the data controller? Bob (the requesting party) is a data processor, because he's following the rules that Alice set out for him? But then he becomes a data controller (another data controller, with a different purpose) when he uses his access. CR today is about data privacy, not about IoT (though Eve notes the ePrivacy regulation mentions IoT). Let's find a use case that encompasses both CR and UMA. How about using the Aggregating and Sharing Pension Information UMA case study <https://kantarainitiative.org/confluence/display/uma/Case+Studies>? (Sal notes it's similar to this Massachusetts search feature <https://www.findmassmoney.com/>.) We seem to have some gaps. What are the specific roles? What is the role of timing? The time of consent is the time you must be prepared to issue a receipt. The data controller must be prepared to issue a receipt to the data subject – or rather, we think that would be nice; some of that data would be included in a subject access request, but "consent receipts" aren't included as such. But what if, as our analysis, the (a) data controller is the data subject, or at least their proxy? Andi: When a resource owner decides who is going to have access and what kind, which could happen multiple times, presumably that's an occasion for generating a receipt. Similarly, when a resource server makes a decision on receiving an access token and a resource request. Andrew envisions the UMA roles flipping from data subject to data controller to data processor at different stages. Can we capture state changes and each of the UMA roles, and try to pinpoint what their "data *" roles are supposed to be? There are a lot of verbs that might work for "agrees to something", depending on the circumstances. Permits, approves, grants access, becomes a party to a transaction...! Robert: Every new subject/controller agreement needs a receipt. The receipt is just the metadata. Sal: It's a relationship! - Enumerate the possible places in UMA where things would be useful to "record"/have a "receipt" structure - See also IIW XXI "Consent Receipts in UMA" session notes (also known as "pumpkin security theater") – page 38 <https://github.com/windley/IIW_homepage/raw/gh-pages/assets/proceedings/IIW…> - Enumerate places where the UMA resource owner and requesting party would find it useful to get a receipt ("repudiation" use cases) Eve showed the Legal slides where the OAuth client credentials, ToS/PN, PAT, (optional) PCT, and RPT get issued. They can also be revoked. - Enumerate relevant technical artifacts in UMA and their places of issuance and usage - Record next steps *AI:* Andrew, Eve, Robert, Andi: Work on UMA/receipt state changes spreadsheet. Put some thinking into the "relationship" angle. *AI:* Andrew, Eve: Find next time for a joint meeting. UMA agenda - Update on spec timeline progress and GOTV efforts - Update on new logo selection Mike asked his colleagues and they don't like the new logo. [image: (smile)] Regarding the "2", he points out that OAuth 1 was huge, and with a 2.0, he worries about a 3.0 and changing his client software. Jin likes the middle one. Adrian doesn't think the "2" is necessarily useful, and thinks having a distinctive design (e.g. with the circle) is useful. Having the blue and green does add cost in printing. - Update on plan to switch to GoToMeeting in 2018 Eve will freshen up the calendar event invites in 2018 with this info; our current events don't extend past 2017. Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico (first hour) 2. Sal 3. Andi (second hour) 4. Maciej (second hour) 5. Eve 6. Mike (second hour) Non-voting participants: - John - Mark - Mary - Andrew - Adrian - Jin (second hour) - Bjorn (second hour) - Tim (second hour) Other participants from the CIS WG *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0