- WG-UMA - mailman.kantarainitiative.org

Agenda for UMA telecon 2016-09-01
by Eve Maler 31 Aug '16

31 Aug '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-01 Date and Time - *Thursdays,* 9-10am PT - Skype: +99051000000481 / US +1-805-309-2350 / international lines <https://www.turbobridge.com/join.html> / web calling interface <https://panel.turbobridge.com/webcall/> / code 1782540 - Screen sharing: http://join.me/findthomas - NOTE: do not use the join.me dial-in line - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2016-08-16 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-08-18> - Review latest editors' draft specs - Core is up to 01 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-01.html> - RSR is up to 00 <https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-00.html> - UMA refresh/saved consent/persisted claims token? - Client awareness of scopes and set math - See 2016-06-02 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-02> , 2016-06-16 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-16?…>, and 2016-08-04 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-08-04> notes - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Submission to the Officer of the Privacy Commissioner of Canada
by Mark OCG 30 Aug '16

30 Aug '16

Hi All, I put forward a submission to the Privacy Commissioner and had a bunch of help from the friends of the consent receipt effort. The submission was changed and edited and revised more than a few times, so, not sure which version will actually be submitted and published by the OPC. But, the final version is attached and this is what is essentially being presented at Helsinki, with most of those mentioned actually presenting in the session I am hosting tomorrow at the MyData. Of course all comments and feedback are welcome, and, I hope that this might be useful to those working in this space. Kind Regards, Mark

2 1

Enjoy
by john＠wunderlich.ca 29 Aug '16

29 Aug '16

FYI For some reason this resonates Unicode Source: http://xkcd.com/1726/ (via Mr. Reader) Thanks, John Wunderlich @PrivacyCDN Pleez 4give speling errurs, sent from a mobile device. -- 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

The best privacy paper in years - UMA
by Adrian Gropper 28 Aug '16

28 Aug '16

The paper is a must-read for anyone trying to understand scope design of APIs as well as those that would design registries or trust frameworks to guide users that are considering signing up for an new app or web service. https://arxiv.org/abs/1608.05661 arXiv:1608.05661 (*cross-listing*) Date: Thu, 18 Aug 2016 07:36:11 GMT (2469kb,D) Title: The Curious Case of the PDF Converter that Likes Mozart: Dissecting and Mitigating the Privacy Risk of Personal Cloud Apps Authors: Hamza Harkous, Rameez Rahman, Bojan Karlas, Karl Aberer Categories: cs.CY cs.HC Journal-ref: Proceedings on Privacy Enhancing Technologies. Volume 2016, Issue 4, Pages 123-143, ISSN (Online) 2299-0984 DOI: 10.1515/popets-2016-0032 \\ Third party apps that work on top of personal cloud services such as Google Drive and Dropbox, require access to the user's data in order to provide some functionality. Through detailed analysis of a hundred popular Google Drive apps from Google's Chrome store, we discover that the existing permission model is quite often misused: around two thirds of analyzed apps are over-privileged, i.e., they access more data than is needed for them to function. In this work, we analyze three different permission models that aim to discourage users from installing over-privileged apps. In experiments with 210 real users, we discover that the most successful permission model is our novel ensemble method that we call Far-reaching Insights. Far-reaching Insights inform the users about the data-driven insights that apps can make about them (e.g., their topics of interest, collaboration and activity patterns etc.) Thus, they seek to bridge the gap between what third parties can actually know about users and users perception of their privacy leakage. The efficacy of Far-reaching Insights in bridging this gap is demonstrated by our results, as Far-reaching Insights prove to be, on average, twice as effective as the current model in discouraging users from installing over-privileged apps. In an effort for promoting general privacy awareness, we deploy a publicly available privacy oriented app store that uses Far-reaching Insights. Based on the knowledge extracted from data of the store's users (over 115 gigabytes of Google Drive data from 1440 users with 662 installed apps), we also delineate the ecosystem for third-party cloud apps from the standpoint of developers and cloud providers. Finally, we present several general recommendations that can guide other future works in the area of privacy for the cloud. -- 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

Regrets for Wednesday
by John Wunderlich 23 Aug '16

23 Aug '16

Hi; I have client meetings that have been called for 10:30 and 11:30 tomorrow, so will be unable to make the CIS and UMA workgroup calls. Regrets. Sincerely, John Wunderlich @PrivacyCDN Call: +1 (647) 669-4749 eMail: john(a)wunderlich.ca -- 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

In lieu of a meeting next week
by Eve Maler 19 Aug '16

19 Aug '16

Hi folks-- I've made a few more edits reflecting a bit of this week's work and a few editing instructions from weeks gone by. You can seen the results in the links below (only Core saw changes). https://github.com/KantaraInitiative/wg-uma/commits/mpd-edits https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-01.html https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-00.html I'd like to suggest that some good activities this week, for those inclined, would be to: - Review the new spec bits - Search for and study all the "[DISCUSS: ...]" parts in Core - Put some thought (and even sketched-out text??) into a more formal "UMA grant type" -- here <https://tools.ietf.org/html/rfc6749#section-4.5> is the bare minimum required by the OAuth spec and here <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-08-18> is what we wrote down at/after today's meeting (see final bullet list) - Weigh in on the list about all this I will hope for some interesting list discussion to catch up on as of August 27. :-) TTFN! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA legal telecon 2016-08-19
by Eve Maler 19 Aug '16

19 Aug '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… Date and Time - *Fridays,* 8-9am PT - Voice: Skype: +99051000000481 / US +1-805-309-2350 / international lines <https://www.turbobridge.com/join.html> / web interface <https://panel.turbobridge.com/webcall/>, code 178-2540# - Screen sharing: http://join.me/findthomas – NOTE: do not use the join.me dial-in line - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar 2016-08-19 - Working session on User-Managed Access (UMA) in Contractual and Regulatory Contexts <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…> - We can make progress with the current scenario *NOTE:* No meeting next week! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Authorization for a Date or Page Range in UMA
by Adrian Gropper 19 Aug '16

19 Aug '16

Issuing an API authorization for a date or page range is very common. It occurs when accessing a resource like a journal with a limited subscription or a page within a much larger collection. Assuming a resource has date or page metadata and is registered with an AS, how does UMA issue a range-limited authorization? Adrian

2 4

Draft minutes of UMA telecon 2016-08-18
by Eve Maler 18 Aug '16

18 Aug '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-08-18 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2016-06-30 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-30> , 2016-07-07 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-07-07> , 2016-07-14 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-07-14>: Moved by Andi, seconded by Jeffrey: APPROVED by unanimous consent. Review new editors' draft of Core spec Discussion about the #155 edit on RSR: Before this edit <https://github.com/KantaraInitiative/wg-uma/commit/0cdb675b1a0d2aaba5028d08…>, we just said all other operations "are unsupported", and there's an error defined for unsupported operations. But MUST NOT is very strong. Saying something like "unsupported by this specification" could be better. Or "Other operations are undefined by this specification; where interoperability by independently implemented services is desired, it is RECOMMENDED to write an extension" or something. "Undefined by this specification" or "out of scope" seems the most neutral. Spec instructions: - Keep this commit <https://github.com/KantaraInitiative/wg-uma/commit/0cdb675b1a0d2aaba5028d08…> but change MUST NOT to "is undefined" We can close #155 and #159. Discussion of #153/#154: Note that the rationale for the "saved consent token" (SCT) name is that the "requesting party token" (RPT), which is now a true OAuth access token in form/format, will also have its own regular OAuth refresh token, and the SCT thingie will have an explicit purpose to capture RqP consent/authorization, much as a traditional OAuth access token's purpose will be. The authorization API as was is now an authorization interface that is both client- and requesting party-facing, with an OAuth extension grant called an UMA grant that starts precisely where the client first "touches" the AS. Are there any implications of HTTP's updating (the updates to RFC2616) to the UMA grant definition plans? We suspect not. Our specs don't point directly to HTTP, only OAuth; it's the OAuth token binding spec (not just RFC6750) that should take special note of the HTTP updates. Consensus on the interface/grant approach. We have removed the UMA-specific RPT endpoint entirely, and we are overloading the existing OAuth token endpoint to produce an RPT (what we're still calling it for the moment, though its form/format will change) and we're giving a portion of the UMA flow around that a name: the UMA grant. The original flow was already quite similar, but took place at a special endpoint that was OAuth-protected with a scope called uma_authorization. Saved consent token definition: The original Core Sec 1.3.2 definition of an AAT said: "An AAT binds a requesting party, a client being used by that party, and an authorization server that protects resources this client is seeking access to on this requesting party's behalf. It is not specific to any resource server or resource owner. The issuance of an AAT represents the approval of this requesting party for this client to engage with this authorization server to supply claims..." Quite a lot of that is applicable to an SCT too. Should we add that to its Terminology definition? George asks: How does the time-to-live strategy work? This goes with our DISCUSS points in the Core 00 draft's Sec 3.5.3.1 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-00.html>. Is correlation with the RPT the correct thing to do? (We continued informally as people started to drop off.) The original idea behind an SCT (was "URT") was that the binding is just like AAT but happening later than the AAT point in time. It should be possible to get this token with the refresh token grant type. Could it be treated truly as a scope (the "save consent" scope) and not a token? We're starting to get a glimmer of where Justin was going. ...except that our new UMA grant needs to be much more full specified because we need to spell out: - How the UMA client's own OAuth client credentials flow to the AS as part of this grant - How the access token (RPT) is issued - Whether an OAuth refresh token is issued (we think so) and its particulars - How the SCT comes into it, and whether it's a "token" or a "ticket"-like thing We really need a conversation with Justin next to sort out his existing implementation and where we'd like to go next in terms of spec details. We suspect that it's most like a client credentials flow, ++. The interaction endpoint on the AS would produce a consent token (ticket-like thing attached to the RPT as metadata?). Or do we need a unique consent endpoint? Can we reuse the OAuth authorization endpoint for that?? It's got the right semantic; the only problem is that it requires authentication. Our UMA-specific interaction (claims) endpoint is better designed. Adrian notes that Michael Chen's EHR system, used by 20,000 people, has a challenge in that it needs to know which person is using the system but the hospitals need policies regarding which client is accessing the resource but doesn't want to manage groups, roles, etc. They want to give out data based on client, not by user. They want accountability at the requesting party level for break-glass use cases (Dr. Jones vs. Dr. Smith), but the policies are not specific to the requesting party. They need to audit access by the specific party. Doctors work in coverage groups. Client awareness of scopes and set math See 2016-06-02 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-02> , 2016-06-16 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-16?…>, and 2016-08-04 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-08-04> notes. Last time we said: "Let's discuss client registration for scopes more next time." Deferred. Attendees As of 1 Aug 2016, quorum is 6 of 11. (Domenico, Sal, Nagesh, Andi, Robert, Paul, Maciej, Eve, Jeffrey, Mike, Sarah) 1. Domenico 2. Andi 3. Eve 4. Jeffrey 5. Sarah 6. Mike Non-voting participants: - Adrian - Jin - Kathleen - Venkat - Ishan - George *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

New editors' spec drafts for the WG to review
by Eve Maler 18 Aug '16

18 Aug '16

If you are active in the wg-uma repository, you'll want to go and sync. Maciej and I are working in the mpd-edits branch. Tomorrow we'll be looking at: https://github.com/KantaraInitiative/wg-uma/commits/mpd-edits (top ~6 commits) https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-00.html https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-00.html Notice that editors' drafts will be in .../uma/ed, and any drafts that get WG consensus (we can actually do WG votes anytime we like) can be held in .../uma/wg instead as stable "checkpoint drafts". *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1