August 2016 - WG-UMA - mailman.kantarainitiative.org

Thoughts on resource set scope "math"
by George Fletcher 06 Nov '16

06 Nov '16

Assumptions: 1. In UMA, scopes are really "per user" rather than per API. Now it is unlikely, and not encouraged, that an RS would produce an API where the scopes are really unique to each user. In most cases it is more likely that the RS will have a set of defined scopes that work across their entire API and hence across all registered resources. 2. For any given resource set, a subset of the full list of the scopes supported by the RS may be registered. Sets of scopes as identified in the meeting notes from 2016-06-02 [1] 1. The universe of scopes the RS has registered for the resource set 2. The scopes the client has registered for at the AS (if it has done this at all) 1. Note that I would add to this that this list of scopes should rather be the list of scopes the AS has determined the client is allowed to request 3. What the RO has attached to the policy for the resource set 4. What the RS requests for at the permission endpoint (in order to get a ticket) 5. The scopes the client requests at the token endpoint Possible algorithm for determining the set of scopes to be issued with a permissions ticket. * The max possible set of scopes that could be returned from the /token endpoint when requesting a token is the "universe of scopes the RS has registered for the resource set" identified by the permissions-ticket * The allowed set of scopes that can be issued by the UMA AS is the INTERSECTION of "universe of scopes [#1]" and the scopes allowed by the RO policy for that resource set [#3]. Let's give this resulting set a number of [#6] {allowed scopes for the resource set} * The list of scopes requested by the client is determined by the INTERSECTION of [#2] and [#5]. Let's give this resulting set a number of [#7] {scopes the client is allowed to request} * The set of requested scopes is the UNION of set [#7] and set [#4]. Let's give this resulting set a number of [#8]. * The max scopes that can be allowed for this access_token request is the INTERSECTION of set [#6] and set [#8]. Mapping this to pseudo-code: Set PossibleScopes = RegisteredResourceSetScopes INTERSECTION ROAllowedScopes Set ClientScopes = ASAllowedClientScopes INTERSECTION ClientRequestedScopes Set RequestedScopes = ClientScopes UNION PermissionTicketScopes Set AllowedScopes = PossibleScopes UNION RequestedScopes Thanks, George [1] https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-02

5 6

Thinking about shifting the Thu Sep 8 call to Fri Sep 9
by Eve Maler 01 Sep '16

01 Sep '16

We've been making pretty good "dog days progress" despite a few interruptions. *This week we definitely meet as normal* for the WG call on Thu Sep 1 and the legal call on Fri Sep 2. I've just had a conflict arise for the following week, and wonder if we should shift our call *from Thu Sep 8, 9am PT to Fri Sep 9, 9am PT*, such that the legal call would be followed by the WG call. Can I get any *"amens" in private email*? I'll reschedule if it looks viable. Unfortunately, my upcoming work travel schedule looks as insane as the IIW/EIC/CIS season did. So as to avoid lots of cancellations, *would a general "backup time" as outlined above* be useful in a pinch? Please *let me know* what you think of that option in your response too. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 1

Comments on "Saved Consent Token"
by Domenico Catalano 01 Sep '16

01 Sep '16

Hi all, Here are some considerations/comments about SCT (Saved Consent Token): 1. SCT could be considered as session token or session identifier for managing RqP/Client interactions with AS for the trust elevation process, for keeping transparent the subsequent actions. The use case is when Bob (RqP) attempts to access to a protected resouce, obtaining a RPT+SCT. Later (10 min), when he tries to access to a new protected resource which match the previouse claims policy, having an active session (on AS), the client posts the SCT which proof that he has previously released the claims, avoiding the claims gathering again. 2. As session identifier token, it should follow the three rules: unique, random and encrypted. Validity is important as well. 3. Maybe the name "Saved consent Token" could be confusing because of "consent" word, which recall compliance terminology. I hope this is helpful for the discussion. Domenico Sent from my iPad

4 5

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

Agenda for UMA telecon 2016-08-18
by Eve Maler 17 Aug '16

17 Aug '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-08-18 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-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> - *N.B.:* No meeting next week - For reference: MPD sequence diagram <http://www.websequencediagrams.com/files/render?link=2DdzslbnVj3ShhlrLVV-> and generic low-level sequence diagram <http://www.websequencediagrams.com/files/render?link=V0tZE2kWrO0l-tGlZX1a> - Review new editors' draft of Core spec (forthcoming on Wednesday) - Client awareness of scopes and set math <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-02> if time - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

FYI
by John Wunderlich 10 Aug '16

10 Aug '16

Just posted this on a privacy list in Canada, but thought you might be interested: <clip> Last week the headline was: "Microsoft shops crowd sentiment analysis engine to Republic and Democratic National Conventions <http://mspoweruser.com/microsoft-shops-crowd-sentiment-analysis-engine-to-r…>" where the lead line was about Microsoft monetizing their research. Today the headline is: "Romanian spies want to spot faces in a crowd - illegally, say human rights groups <http://www.zdnet.com/article/romanian-spies-want-to-spot-faces-in-a-crowd-i…>" In their defence, the intelligence agency says that "The system does not collect new data. It only analyses existing data, based on algorithms." OK then. That makes it all right. I can't think of a better demonstration of the necessity for transparency and public oversight in the development and deployment of technologies that collect, use or disclose information about individuals. If the most profitable markets are political parties and intelligence agencies who want to collect the information for good (our guys) or ill (their guys) then in the absence of any other influence, companies go into those markets. <clip> This highlights the importance of the proactive tools that we are developing, like user submitted terms & UMA, along with the consent receipt for accountability. 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

Notes from UMA telecon 2016-08-04
by Eve Maler 08 Aug '16

08 Aug '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-08-04 MinutesRoll call Quorum not reached. Critical mass for rough consensus 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>: tbs Logistics - *Note:* No WG calls on August 11 and August 25. (Also no legal subgroup calls on August 12 and August 26.) - Do we want to refresh our "pointer Internet-Drafts" (core <https://www.ietf.org/archive/id/draft-hardjono-oauth-umacore-14.txt> and RSR <https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-07>), wait till we have new finished versions, or never update them again? If we have no opinion on the IETF I-D question, we'll take no action *at least* until we publish final versions of our next specs. Spec text update Eve shared status on our work against our roadmap <http://kantarainitiative.org/confluence/display/uma/UMA+Roadmap+for+2016>. We are substantially through the items, with the devil being in the detail (actual spec text). What's a reasonable timeframe for completion of said roadmap? Stability of specs with chance to implement and test by end of year, with ratification (membership voting) plans after that? Sarah thinks so. No other opinions expressed. [image: (smile)] Eve's thinking on the balance to be achieved: There's keen interest in wide ecosystem use cases, but pressure to get big changes right. Client awareness of scopes and set math See 2016-06-02 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-02> and 2016-06-16 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-16?…> notes. In the latter set of notes, there's a discussion about how clients are free to request more scopes and RS's are free to register fewer than what the client requested. George believes that the reason to allow the client to request scopes at all is to reduce chattiness (in the case that the client is smart enough to know what it wants and can handle). In other words, if the client knows it wants scopes A, B, and C, it can request all of them up front. And so we need to preserve the scope-unawareness flow when the client isn't that smart. Adrian adds that data minimization suggests that the client should ask for as few scopes that it needs to do its job; we should probably be adding some non-normative spec text in the security and privacy considerations about this, inspired by the OAuth specs. The RS, as an API publisher, will need to account for scopes that are common to the kinds of resource sets that they (the scopes) are on. The kinds/types/classes vs. instances (with rsid's) distinction is reminiscent of the solution we thought we came up with last week for standardizing FHIR/HEART resource set and scope semantics (or any standard/public API that is implemented by multiple API publishers). So, in terms of the list in the 06-02 list for set math purposes, there's a #0 on the list that is the "API documentation", likely in Swagger or Swagger++, which says "here are the scopes for this API and how to use them" and, if there are resource set types, "here are the resource set types with which the scopes are associated". That's the "class" level, whereas RSR is the "instance" (RO context) level. Clients have to implement what the API publisher says is available to implement. Standard APIs are only different from proprietary APIs in that the API documentation is standardized (and, perhaps, will include our "trick" for protection API extensibility profile). Is it recommended for security to register for the scopes they want? Is it hairy compared to other scopes because some scopes might be specific to only some resource sets? Actually, as long as the scopes are distinguished by URI in a per-resource set way, the friendly name could still be (say) "Read" and they'd be unique per resource set. This is up to the RS to manage. However, the actual registration process may look a bit different from today's OAuth scope registration process. Let's discuss client registration for scopes more next time. Spec text instructions (issue 159): - Now that the client can ask for scopes, add security and privacy considerations as mentioned above - Say something about how RS's need to include API documentation about scopes (as step 0), and how that ties to step 1 Client-to-AS-first flow Though we have put this aside for now, it's still on our 2016 roadmap docket. There is interest in it, and also a question about implications for HEART. Resource set ID context for standardized semantics profile idea See these notes <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-07-28> . We dug into this a tiny bit, but only insofar as it pushed the client awareness of scopes topic forward. 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. Maciej 3. Eve 4. Sarah Non-voting participants: - Kathleen - Ishan - Robert - François - Adrian - Scott F - James - George Regrets: - Justin - Sal - John W - Mike *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 3

Re: [WG-UMA] [WG-InfoSharing] Article 29 Working Party Releases Opinion on the R...
by John Wunderlich 07 Aug '16

07 Aug '16

James; I’m unaware of such a group collaboration with respect to the GDPR, but would also love to find out about it if it exists. I’ve had to read the GDPR end to end a number of times recently for an engagement I had. It will be interesting to see how what you call, I think correctly, “a powerful point of view”, interacts with the also powerful forces of commercial inertia that have build the personal data ecosystem based on a de facto treatment of personal data as property. My experiences with large enterprises suggests that we are at the confluence of a number of development curves: 1. *Personal Data Economy*: This is how the Internet was monetized and is fully mature. It is predicated on contracts of adhesion or terms of use that enable one way doors for the collection of personal information by entities that then get to use that data as they see fit, with marginal constraints that appear occasionally if a particularly heinous security or privacy incident reaches a regulator or the press. This is in many ways a mature market. 2. *Big Data*: Moore’s law has put affordable big data on the table. Despite the hype in the media and with VC’s my suspicion is that actual useful big data installations are still at the Early Adopters stage. Much of the predicted profit from Big Data comes from the personal data economy and assumes unfettered access to data lakes of personal information . This is where ‘innovation’ is happening. And it’s not good for the GDPR or our personal data autonomy generally. Notwithstanding nattering about these innovations, large organizations with a dependency on the status quo will push back hard against anything that might require a change in business model or business processes. Similarly, startups seeking VC money tend to articulate their MVP in terms of existing schema for profit and monetization. A couple of cliché’s come to mind involving rocks and hard places or immovable objects and irresistible forces. This is why the Kantara Incubator <https://kantarainitiative.org/confluence/display/ccicada/Home> is so necessary and exciting. It presents researchers and startups with an opportunity to innovate against the mature personal data economy itself, rather than try and come up with news ways of monetization (which is essentially all that the current big data initiatives appear to be). I don’t know what the successor to the Personal Data Economy will be. It may be as simple as the Personalized Data Economy, where the locus of control shifts from the data controller to the subject. But it seems clear that the GDPR and the Personal Data Economy as it is currently constituted are mutually incompatible. - Sincerely, John Wunderlich @PrivacyCDN Call: +1 (647) 669-4749 eMail: john(a)wunderlich.ca On 7 August 2016 at 11:51, James Hazard <james.g.hazard(a)gmail.com> wrote: > Yes, nice summary. The official introduction to the GDPR - the > legislative whereas-es - is as good a work of digesting a complex legal > subject matter as I have ever seen. In its _173_ sections of introduction, > it touches on a great deal of the landscape - interactions of privacy, > security, national differences, technology, judicial systems, legislation, > etc. Yet still present a powerful point of view and specific positions. > > Is anyone aware of a place where this - the GDPR as a whole or the > introduction - is collaboratively commented? I would love to know of it. > > http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/? > uri=CELEX:32016R0679&from=EN > > > On Sun, Aug 7, 2016 at 6:47 AM, John Wunderlich <john(a)wunderlich.ca> > wrote: > >> Nice summary >> >> http://www.dataprotectionreport.com/2016/08/article-29- >> working-party-releases-opinion-on-the-revision-of-the-eprivacy-directive/ >> >> >> >> John Wunderlich, >> >> Sent frum a mobile device, >> Pleez 4give speling erurz >> >> "...a world of near-total surveillance and endless record-keeping is >> likely to be one with less liberty, less experimentation, and certainly far >> less joy..." A. Michael Froomkin >> >> >> >> 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. >> >> _______________________________________________ >> WG-InfoSharing mailing list >> WG-InfoSharing(a)kantarainitiative.org >> http://kantarainitiative.org/mailman/listinfo/wg-infosharing >> >> > > > -- > @commonaccord > -- 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.

2 1

Creative names for consent in UMA [Legal]
by Adrian Gropper 05 Aug '16

05 Aug '16

Today's legal call was about the contract between the Grantor and the AS - or is it the ASO? As I understand it, we're looking for language to describe the relationship between the grantor / resource owner and her agent that will be operating an authorization service on her behalf. The section on Agents starts at page 67: http://docplayer.net/4194796-Restatement-of-the-law-agency-restatement-thir… The description of fiduciary duty seems to be quite clear. Page 72 deals with Principal's Consent. The key paragraphs are (my underline): - (1)(a)(ii) (ii) discloses all material facts that the agent knows, has reason to know, or should know would reasonably affect the principal's judgment unless the principal has manifested that such facts are already known by the principal *or that the principal does not wish to know them* - (1)(b) (b) the principal's consent concerns either a specific act or transaction, or acts or transactions of *a spe**cified type that could reasonably be expected to occur* in the ordinary course of the agency relationship. When Alice is informed about a particular transaction by the agent (in UMA this means that Alice is alerted to the specific RqP, Client, and Scopes) the situation is clear because Alice is more or less in the authorization loop. I would not use consent to describe this kind of transparency but IANAL. Under what circumstances can the Agent be less transparent? Regardless of our creativity in adding modifiers like "dynamic" to consent, the key points are underlined by me as - A positive statement by Alice that she doesn't want to be notified, or - A "specified type that could reasonably be expected to occur". I propose that the only way to get closure on this topic is by focusing on these two issues when Alice is signing a contract with an AS as a separate entity. The burden is on the ASO to adequately describe to Alice the specifications of the transactions that she will not be notified about and that are reasonably expected to occur. Alice would then use these descriptions in court in case of dispute. Adrian -- 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 3

Notes from UMA legal telecon 2016-08-05
by Eve Maler 05 Aug '16

05 Aug '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2016-08-05 - Review User-Managed Access (UMA) in Contractual and Regulatory Contexts <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…> - Nailing down the right 1-2 paragraph scenario for use throughout the document (send your alternatives before the meeting) Attending: Eve, Kathleen, Andrew H, Adrian, Mary, Jim, John *NOTE:* No meeting next week! Regarding finding the right scenario: Smart home scenarios are really just as important due to sensitivity as health scenarios. In health research, it looks like the first BSC use case is going to get more complex still because real-life scenarios are getting blocked due to patients' reluctance to consent without a way to be notified of additional researchers' requests to access. Jim notes that "broad" consent is the key problem – anticipating future needs. And speaking of this, Adrian dislikes "informed" consent, because people don't know what's going to be done with it later. Transparency in being kept aware of status and where else the data is traveling is a key part of resource owner empowerment. Our discussion this time is ranging all over, but it all seems related to our hoped-for Regulatory section. Maybe we need a discussion in the Regulatory section about what "consent" maps to in UMA's "authorization" concept. There is a notion of authorization as a thing that can be dynamic – an RO can grant authorization and later revoke it (by an interaction with the AS that is actually outside the protocol but in scope for our model text), at a grain that is finer than Ts & Cs, and empowered by that grain, by the option to "Share" at will, and by the option to "un-share" any portion of the resource at will. John likes the phrase "Dynamic Consent"... It may be taken already. See this Nature article <http://www.nature.com/ejhg/journal/v23/n2/full/ejhg201471a.html>. Hazard@All: could have an obligation on the data user to destroy. Like my passport number for a hotel stay. Hazard@All: but once the other guy has it, we need to rely on some other method to have them delete it. Hazard@All: either contract or escrow Hazard@All: that is a matter of legal verbiage, I think Hazard@All: the lawyers phrase it however seems to work Hazard@All: and the vocabulary will change based on dozens of factors, including the common vocabulary of the business sector, jurisdiction and language Hazard@All: notice can be specified however you want - right? Hazard@All: you can use my stuff but you agree to text me whenever you do. Would we have to deal with privacy/data protection regulations as property-based vs. rights-based in our model text? We may very well, but it needs more discussion. Could Jeffrey apply his model? *AI:* Eve: Ask if Jeffrey would be willing to adapt his Information Governance school assignment into a small scenario for the primer, adding Alice to it, as an alternative scenario for consideration. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

FYI: Paper on cloud personal data privacy
by John Wunderlich 05 Aug '16

05 Aug '16

https://www.academia.edu/27238178/Approaches_on_Personal_Data_Privacy_Prese… 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

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

04 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-05 - Review User-Managed Access (UMA) in Contractual and Regulatory Contexts <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…> - Nailing down the right 1-2 paragraph scenario for use throughout the document (send your alternatives before the meeting) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Apple is trying to patent UMA
by Adrian Gropper 03 Aug '16

03 Aug '16

We must be on the right track. http://www.patentlyapple.com/patently-apple/2016/07/apples-patent-pending-i… Adrian -- 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

Sigh, I did not just mean to delete Thursday's call from our calendar
by Eve Maler 03 Aug '16

03 Aug '16

I'm putting it back right now. We're still on. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2016-08-04
by Eve Maler 03 Aug '16

03 Aug '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-08-04 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-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> - Logistics items - Telecon interruptions - I-D expirations - For reference: MPD sequence diagram <http://www.websequencediagrams.com/files/render?link=2DdzslbnVj3ShhlrLVV-> and generic low-level sequence diagram <http://www.websequencediagrams.com/files/render?link=V0tZE2kWrO0l-tGlZX1a> - Client awareness of scopes and set math <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-02> - How to give resource set ID context to standardized resource set and scope semantics profile idea <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-07-28> ? - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Transferring standardized resource set and scope semantics out of band: digging deeper
by Eve Maler 01 Aug '16

01 Aug '16

Last Thursday we got this far in our understanding about transferring standardized resource set and scope semantics (say, as captured in the FHIR API or some other large, complex API implemented by multiple independent service operators) out of band of the UMA RSR process: http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-07-28 The AS would declare that it's using the protection API extensibility profile, meaning that it's prepare to go outside the normal AS-RS communication route for some part of its interaction with RS's. The community around the relevant API would define an extension profile. (We didn't talk about this, but such an extension profile would define an URI as an identifier, and this URI would be referenced in the AS config data/discovery document, advertising its compatibility with that profile.) The profile would, we believe, possibly involve explicit registration of a "bootstrap" resource that signals implicit registration of other resources that have standardized "type" fields. It occurs to me that what's incomplete about this scheme (at a minimum -- there may be other things missing) is that, in explicit RSR, we register "instances" and not "types" of resource sets, and the RS gets back from the AS a specific resource set ID that has been dynamically created for it, and can't *tell* the AS what resource set ID it wants. E.g., let's say that the RS registers a "bootstrap resource set" of "FHIR:EHR" type with the AS on Alice's behalf (and gets back a resource set ID of "foo"), which the HEART-UMA-FHIR profile defines as signaling that a whole bunch of other "sub-resource sets" of other specific types should be automatically registered too, like one with the "FHIR:medicationlist" type and one with the "FHIR:allergylist" type and whatever. What, exactly, are their resource set IDs in the Alice context? Since we had wanted to create these implicitly and not with an API call, how would the RS be informed of what these are? Or do we have to actually invent new bulk ways of doing this in-band? (In a draft version of the RSR API, we used PUT instead of POST, which enabled the RS to dictate its own resource set IDs, but gave that up for very good reasons.) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 2