- WG-UMA - mailman.kantarainitiative.org

Is HEART profiling privacy?
by Adrian Gropper 20 Jun '16

20 Jun '16

I doubt that I'm alone in being totally confused by Eve's use-case as it relates to developing a HEART profile. But just in case, I'm putting my concern in a separate thread. I'm cross-posting to the UMA group because there's an active thread there about scopes right now. Let me try to convince you that there's no need for HEART to be profiling privacy and that trying to do so would do more harm than good. During today's HEART call we agreed that "Alice completely trusts her UMA Authorization Server." I take this to mean that Alice has no reason to restrict her Resource Type registration with the UMA Authorization Server to anything less than 'FHIR'/patient/* . Any subsequent restrictions or scoping would then be decided by the AS based on Alice's policies and client needs. FHIR, in its evolving wisdom, will define and standardize hundreds of resource types below patient as 'FHIR'/patient/xyz. Alice's AS will take the applicable FHIR standard and expose a policy-setting UI to Alice well before the time that the FHIR client shows up. The FHIR clients will have access to the FHIR standard and will therefore know what the standard resource types are. Of course, some FHIR resource servers may not implement the entire set of hundreds of potential resource types, maybe because they don't handle that kind of patient data, but let's not get ahead of ourselves. The point of UMA is that Alice can set and can change her policies at any time between the time of resource registration and before the FHIR client shows up to her AS. Alice can do this policy setting based on either: - the published set of FHIR patient-level resource types, or - the subset of resource types that the particular FHIR Resource Server actually supports for all patients, or - the subset of resource types that the FHIR Resource Server supports in her particular case. Which brings us to my question: What purpose is served by HEART profiling some subset of the FHIR patient-level resource types? Presumably it's to improve her user experience at her AS by "graying out" privacy options supported by the FHIR standard but not offered by that particular FHIR Resource Server. This "graying out" is purely a user experience issue. It has nothing to do with interoperability because no harm is done if Alice chooses to restrict or enable resource types that are not supported by the particular resource server anyway. Much as I like to advocate for a good user experience, giving the FHIR Resource Server a particular subset of "privacy-related" resource types as a profile will do much more harm to interoperability and information blocking than it will do good. It sets a low bar. It restricts the kind of policies that Alice could set if the scope calculus is always done at the point when the FHIR client presents to the AS. In general, (not just FHIR or HEART) any resource server is free to publish the actual subject-level resource types it supports. This is easier when there's a standard. UMA may or may not also provide an endpoint for communicating the resource types that a particular resource server makes available to as particular resource subject. This is a nice-to-have to improve the user experience by "graying out" the resource types that are not available for that particular subject but it is not an interoperability issue. PS: It is often pointed out that merely "graying out" certain resource types for a particular subject could leak private information. This is not an issue if "Alice completely trusts her UMA Authorization Server." In cases where Alice does not have complete trust of her AS, then indeed, she needs to restrict the types of resources that are registered with the AS by using the FHIR resource server's patient portal or some other out-of band mechanism that is beyond both UMA and HEART. 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/

1 0

Registering multiple resource sets
by George Fletcher 20 Jun '16

20 Jun '16

I figured I'd send out some suggestions. In looking at the existing spec [1] (hopefully I'm looking at the most current version) there isn't an easy way to add backward compatible support for registering multiple resources sets with the existing POST to {rsreguri}/resource_set. A couple of options come to mind... 1. If there is only one resource being registered it works as currently defined. If however, multiple are being registered, the what is POST'd is a JSON Array (instead of a JSON object) of the resource set JSON objects... POST /rs/resource_set HTTP/1.1 Content-Type: application/json Authorization: Bearer MHg3OUZEQkZBMjcx ... [ { "name" : "Tweedl Social Service", "icon_uri" : "http://www.example.com/icons/sharesocial.png", "scopes" : [ "read-public", "post-updates", "read-private", "http://www.example.com/scopes/all" ], "type" : "http://www.example.com/rsets/socialstream/140-compatible" }, {...} ] With a response of... HTTP/1.1 201 Created Content-Type: application/json Location: /rs/resource_set/KX3A-39WE ... [ { "_id" : "KX3A-39WE", "user_access_policy_uri" : "http://as.example.com/rs/222/resource/KX3A-39WE/policy" }, { "_id" : "DAFS-94SS", "user_access_policy_uri" : "http://as.example.com/rs/222/resource/DAFS-94SS/policy" } ] I'm not sure I like this (#1) option as it makes coding a little complicated. 2. Add an effective new endpoint for "batch" registrations. This keeps the new functionality separate. I'm sure there are better mechanisms but a simple one would be to use something like POST {rsreguri}/resource_set/batch. Then, like in example 1 above, the resource sets are POST'd as a JSON array of JSON objects. Thanks, George [1] https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0_1.html

2 2

Notes from UMA telecon 2016-06-16 (with help from Ishan)
by Eve Maler 20 Jun '16

20 Jun '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-16 MinutesRoll call Quorum was not reached. Ishan will take notes after Eve drops. Approve minutes Approve minutes of UMA telecon 2016-06-02 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-02>: Deferred. MPD We're looking at the set of scopes involved in step #4 from last meeting <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-02> . Note that a "client-to-AS-first" flow is not part of the MPD change proposals, so let's not discuss any of that now. Take the scenario that the client attempts access with API call "foo", which could represent usage of scopes A, B, C, D, and E. Think of the example of OIDC, where accessing an email address potentially corresponds to the specific claim, "openid", "email", "address", and "profile". (Imagine that OIDC is UMA-protected in this instance.) Another example could be a photo service that allows viewing, printing, drawing a mustache, etc. Do we want to mandate that the RS register a permission that is totally deterministic in terms of how many scopes it registers for the relevant resource set? Justin prefers that the spec give guidance to the RS to register the set of scopes that appear to correspond to the actual client access attempt. Suggested wording: "It is RECOMMENDED that the RS register a set of scopes with the permission ticket that would allow the client's request to succeed." This is close to our current wording, except that it's not a MUST, and would allow less scope than would suffice. What would the various rationales be for the RS registering more, less, or exactly the same as what the client attempted? We can't prescribe scope design, nor the relationship between the RS and client. Since we're planning to make it possible for the client to request more scopes, it should be possible for the RS to register fewer scopes. Eve posed a couple of questions before having to drop: Are we injecting into UMA something that's been seen as a detriment in plain OAuth? It's been seen as a business benefit that UMA up-levels to the business owner the semantics of scopes. Do our permission registration and RSR processes help with this? Also, we have an open issue around registering multiple resource sets. How might we accommodate that? Can we just take it up later? Ishan's notes (thank you!): *Regarding client unawareness of scopes:* In Siteminder, clients were not aware of scopes, enterprise use cases...and continue that pattern. UMA's proposed change does not preclude clients from being unaware of scopes Mike is interested down the road in how this will allow the development of smarter clients and authorization servers. We are adding back OAuth-like flows around scope that make it easier for development of resource servers/APIs. For enterprise use cases, an UMA gateway may be easier to retrofit on top of existing APIs minimizing development. *Regarding the open issue on registering multiple resource sets:* What is the combination of scopes/format for each resource set to determine the scope math? We need to specify a way for allow multiple JSON objects at registration, to allow for backwards compatibility. *A request for discussing the MPD proposal for the next meeting:* - How does the client get the token? ( RPT endpoint -> token endpoint) - Client can specify the set of scopes, and determine scope set math - Splitting the claims presentation options, non interactive; need to involve the RqP that tells the client to send them to an endpoint at the AS - Ticket rotation - handle to the next part of the transaction; one time use - Minor proposed syntax changes In the next meeting, walk the through the MPD sequence diagram to compare/contrast the current UMA flow with the proposed one to eliminate future confusion. (Justin will not be available next week, and will join the call the following week) Attendees As of 12 Jun 2016, quorum is 7 of 13. (François, Domenico, Kathleen, Sal, Nagesh, Thomas, Andi, Robert, Agus, Maciej, Eve, Mike, Sarah) 1. Domenico 2. Kathleen 3. Sal 4. Eve 5. Mike 6. Sarah Non-voting participants: - Justin - Ishan - George - Adrian - James *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

UMA legal subgroup call on Friday is canceled, but...
by Eve Maler 16 Jun '16

16 Jun '16

I'm finally taking a few vacation days, and so I'm unavailable on Friday. However, I've started a GDoc for the Use Cases document <https://docs.google.com/document/d/1ZCS1LMLRefdryDMi8LPMVDsJ2lq_GhIvub2Uj7Z…>, and you can go and edit in it too. It's not much more than an outline so far, but I've added ideas for four more use cases than our "standard four" that we've talked about many times. I think we could make some good progress on it. Please do take a look, and if you're really really disappointed that we're not meeting on Friday, hey, why not draft up one of the use cases? :-) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Client awareness of scopes in UMA / Breakfast BOF tomorrow (Thu Jun 9) at CIS
by Eve Maler 16 Jun '16

16 Jun '16

Still no WG call tomorrow, but it's been suggested to have a BOF -- so for those of us here at CIS, let's plan to meet at 7:30am over breakfast. We could take the opportunity to discuss an item that's coming up in a few conversations: While scopes in OAuth are universal to their protected resources, scopes in UMA are bound to a particular RO context. Thus, in the flow being proposed where clients make scope requests by clients, are the clients: - Making a simplifying assumption about scopes being attached to generic "protected resource classes" (?) of some kind, where specific ROs are bound to instances of these classes later to get RSIDs? - Aware of RSIDs somehow in order to ask for scopes? - Doing something else entirely? The way APIs are generally designed, the first option seems the most likely/reasonable/privacy-protecting. If that's the case, what other design considerations would there (have to) be for scope sets? E.g., our notes from last week had this list in it: 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) 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 There would need to be some insertions and questions answered for at least #1, #2, and #5. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

3 6

Agenda for UMA telecon 2016-06-16
by Eve Maler 15 Jun '16

15 Jun '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-16 *Date and Time* - *Thu Jun 16,* 9-10am PT - Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines <https://www.turbobridge.com/join.html>), room code 178-2540# - Screen sharing: http://join.me/findthomas - *NOTE:* *IGNORE* the join.me dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar *Agenda* - (Eve needs to leave a bit early) - Roll call - Approve minutes of UMA telecon 2016-06-02 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-02> - MPD: Still working through the sequence diagram <http://www.websequencediagrams.com/files/render?link=2DdzslbnVj3ShhlrLVV-> - Client awareness of scopes: replay/conclude discussion at CIS breakfast BOF and on the list; any negative impacts in the dev/business owner relationship? - Get-a-token loops - Next steps on spec text - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Capturing Resource Owner's Dynamic Context
by Mohammad Chowdhury 14 Jun '16

14 Jun '16

Dear All, I am new to this group and spare me if I am asking a dumb question. I am wondering, Is there any way in UMA to capture the dynamic context of the resource owner to provide context-aware authorization? I have the following use case, "Alice's mom will get access to online CC camera hosted in Alice's apartment, Only if Alice is out of her apartment " I know XACML is used to capture the context of the Requester (e.g., subject of XACML, in this case Alice's Mom). But I do not know is there any mechanism in XACML to capture the dynamic context (in our case, context is location) of the resource owner (in this case, Alice ) for authorization decision. Can anyone advise me on this ? Any comment will be appreciated. Kind regards, Jabed

6 5

No WG call or legal call this week
by Eve Maler 07 Jun '16

07 Jun '16

The outcome of my request for input on whether to hold a WG call is that we've cancelled the call. I'd already cancelled the legal subgroup call. Talk to y'all next week! Eve (sent from my iPhone, possibly with Siri's "help": +1-425-345-6756)

1 0

Does a call this Thursday make sense?
by Eve Maler 05 Jun '16

05 Jun '16

[NOTE: I put this on Slack and Skype just now as well: If you're on Slack too, please respond there instead.] Does a call this Thursday make sense? That's the last day of CIS. I can squeeze it into my schedule before flying out for yet another conference (the very last of this crazy six-week stretch for me). I think we can make progress discussing the "loop" element of the swimlane even if Justin can't make it, but it would be ideal to have him present. Please weigh in *on Slack*, *or Skype if you're not on Slack*, *or in private email if you're not on either*, if you can make it, and I’ll decide by Tuesday. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 2

Notes from UMA legal telecon 2016-06-03
by Eve Maler 04 Jun '16

04 Jun '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2016-06-03 - NOTE: No subgroup telecon next week - Privacy@Scale report - Status of outlining/editing of newly planned document deliverables - UMA Legal Primer - UMA Legal Use Cases Attending: Eve, Paul, John W, Mary, Ann, Kathleen, Adrian, Mark *Privacy@Scale and other event reports:* John and Eve both attended on Monday of this week; it was the 2nd annual, and their first. Facebook hosts it. It was in DC this year. John was very vocal. You can find two of the three report deliverables commissioned by Facebook from Ctrl-Shift at this site <http://thedatadriveneconomy.com/>. The third report is coming soon. Eve spoke at FB’s behest on the roundtable process that fed into those reports, and mentioned UMA and Consent Receipts. John points out Omri Ben-Shahar <http://www.law.uchicago.edu/faculty/ben-shahar>’s research (he wrote a book called More Than You Wanted to Know: The Failure of Mandated Disclosure) purporting to show that privacy notices are pointless (he was doing a “point-counterpoint” talk with Lori Cranor). Mark contrasts this (?) with the Project IF <https://projectsbyif.com/> work on “data licenses”, where it seems to matter. On Tue-Wed of this week, Adrian attended the NIST Named Data Networking meeting. This work has significant privacy implications. Relative to UMA, there was a mention of longitudinal health records. But he doesn’t expect movement on this soon. PPR has its annual Health Privacy Summit. Remember: It’s free and streamed. Contact Adrian to get an invite! *New UMA Legal document deliverables:* John did a draft outline of an “UMA Legal Primer”. Eve has her slide deck as a start for something like an “UMA Legal Use Cases” document. What should the real names of these documents mean? “Legal” comes after something like “Business”, “Strategic”, “Real-Life”, etc. The use cases are ideally tackled in a fashion that doesn’t introduce UMA terminology, at least at first. They can introduce UMA terminology as a mapping exercise in a second chapter or something, or even point to the other document. What real-life digital resources should we use for examples in the use cases? Health data is a very real example, but how much should we use this? There’s a sense that we should either spread the examples around, or be cautious/aware about using health examples because of its specialty characteristics. We could introduce RACI mappings once we come out of the “UMA technical” term explanations into the “data *” mappings. Kathleen notes that when we have a 1yo (actually a minor who is legally incompetent but old enough to be aware) Johnny, he is legally incompetent to consent and thus may give assent vs. consent; this maps to “Resource Subject that is not at a Responsible level” or something. IOW, RACI is an imperfect system to map to (as we concluded previously). However, the point is that RACI maps well to “data *”. (John writes this part. :-D ) Further, mapping UMA-technical roles to data-* roles leaves a hole: the AS. It’s not a data-anything. This is the innovation of UMA. The contract roles and relationships is the third plane. We should treat it on its own. The goal of the UMA Model Clauses section would be melding the three dimensions all together. We should take a lightweight approach, point to a couple of illustrative clause samples, and in essence serve as clause documentation. We might need a subsection somewhere in this doc (not as a separate dimension/plane) for the UMA-legal definitions, to support the clause explanations. Eve (John?) will import this into a GDoc for collaborative editing. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0