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

Agenda for UMA legal telecon 2016-06-24
by Eve Maler 23 Jun '16

23 Jun '16

Please note that TurboBridge is still being frustrating, but James P on today's UMA WG call discovered that the web interface (link provided below) was working very nicely for him. Domenico, on the other hand, found that the "Call" button wasn't working for him on Safari... Please give it an extra couple of minutes to try and get into the call, if you can. Thanks! 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-06-24 - Review document deliverables - UMA Legal Primer - UMA Legal Use Cases *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2016-06-23
by Eve Maler 23 Jun '16

23 Jun '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-23 MinutesLogistics Did you know that it's possible to join through the TurboBridge website <https://panel.turbobridge.com/webcall/> for free????? Thanks to James for discovering this! Roll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2016-06-02 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-02>: APPROVED. Implementation page and UMA Dev We discussed the plan of action decided by UMA Dev yesterday <http://kantarainitiative.org/confluence/display/umadev/UMA+Dev+telecon+2016…>. To clarify, we won't question or test their info, just provide it as-is, and we can make that clear. Leadership team elections A candidate motion: MOTION: Moved by Sarah: Approve Eve as Chair, Maciej as Vice-Chair, Domenico as User Experience Editor, and Maciej as UMA Dev WG Liaison for the next year: APPROVED by unanimous consent. AI: Eve: Sort out editor role elections and update the Leadership Team page. AI: Eve: Sort out corresponding UMA Dev elections. Registering multiple resource sets George's proposal was to use the existing REST path we have and use an array/not-array cue for whether we are registering multiple resource sets or a single resource set. According to his research, this seems to be a somewhat common pattern for indicating that the AS is about to get just one thing. Our previous work on the permission registration extension, while not reflected in our latest draft <https://08620661282160442115.googlegroups.com/attach/f218681b41266/draft-um…> in the email archives, was going in the direction of assuming that it's more consistent to have the RS always use an array; the only problem at the time was that this was backwards-incompatible. On what basis should we be making a decision? - Our requirements and design principles <http://kantarainitiative.org/confluence/display/uma/UMA+Requirements> say that the AS should bear more complexity than the RS or client; the RS shouldn't have to help the AS with this. - If the RS is registering one thing vs. multiple things most of the time, it shouldn't have to wrap it in an array. (What are the use cases that drive the percentage of the time? Nagesh prefers the certainty of knowing it's going to be an array vs. picking.) - In an extension we have to care about backwards compatibility, but in a new version where we're already doing other backwards-incompatible things, we don't have to care. Is it really necessary for the RS to explicitly register all of the many resources to give the AS visibility into the structure of an API? Adrian has a vision of informing the AS that the FHIR semantics are in play, and it could know that the relevant sub-resource sets are being protected once the top-level EHR or whatever is registered. FHIR was actually a key motivation for multiple resource set registration in Eve's case. Given that the AS is currently "stupid" with respect to resource set dividing lines, and the RS is authoritative for them, it's important (to her mind) to be sure the RS is actually capable of exploiting the entirety of the currently-flat namespace for resource sets, including experimenting with the possibility of extending resource set description documents. Kathleen notes that there is work on a FHIR Consent structure, and an RDF-OWL FHIR mapping. These could enhance a registered resource set, e.g. by being included with the description document, so that the relevant policies are bound to labeled resources. A use case for using this would be that if you have to do a notification for Accounting of Disclosures, and it has to go to the patient's endpoint, it could be connected to the correct consent downstream. We'll see if we can lock down consensus next time; our current leaning seems to be an "all-array" approach. AI: George: Look at and critique the current permission registration extension text as a candidate for new spec text, from the perspective our current leaning. 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. Nagesh 5. Maciej 6. Eve 7. Mike 8. Sarah Non-voting participants: - Adrian - Scott S - Scott F - James - George - John W Regrets: - Justin *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

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

23 Jun '16

Hi Scott, You're right but it really doesn't matter to HEART. This is the kind of stuff we obsess about in the UMA Legal subgroup where we try to tease apart the various kinds of delegation and how they relate to real-world legal constructs such as "contract" and "agency law". As Debbie said so clearly in another thread, UMA stands for "User" "Managed" "Access". Our work will converge much faster if HEART takes that strictly in the technical sense to mean that the patient has "some technology" that they manage as a technical point-of-contact with the various other actors' technologies including various institutional systems that the patient clearly does _not_ manage. If we weaken this very simple technical definition by making the UMA AS server multiple "managers" then complexity and confusion explodes in two dimensions: legal and technical. On the legal side, every AS has to figure out what it means to be an honest broker between possibly competing interests rather than just an advocate for the patient - simple agency law does not handle this.. On the technical side, every AS has to do some kind of calculus (e.g. XACML) based on the specific legal constraints represented by the policies of multiple masters. The joy is that none of this is necessary. Once we define the AS technology as simply representing the patient, then all other aspects, legal and technical can be rationally distributed among the other actors to serve all of our various use-cases. Adrian On Wed, Jun 22, 2016 at 11:21 AM, Scott Shorter < sshorter(a)kimbleassociates.com> wrote: > Thank you Adrian. > > The next sentence after the example reads “The resource server MUST NOT > give access in the case of an invalid RPT or an RPT associated > with insufficient authorization.” > > Reading those together my interpretation is that the RS is permitted to > deny access for it’s own reasons, but the RS is not permitted to grant > access that the AS has denied. Am I reading it correctly? > > Thanks, > Scott > > On Jun 22, 2016, at 10:59 AM, Adrian Gropper <agropper(a)healthurl.com> > wrote: > > From the Jan 29 minutes: > > The actual UMA Core spec has a clause, which Eve has dubbed the "Adrian > clause": UMA Core Sec 3.3.3 > <https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html#give-access>: > "The resource server MAY apply additional authorization controls when > determining how to respond." > > Adrian > > On Wed, Jun 22, 2016 at 10:31 AM, Scott Shorter < > sshorter(a)kimbleassociates.com> wrote: > >> Hi Adrian, >> >> Thanks for clarifying the distinction. I just realized that my >> understanding of the term authorization server is probably influenced more >> by my familiarity with the 2005 common criteria protection profile >> <https://www.commoncriteriaportal.org/files/ppfiles/PP_AUTHSRV_BR_v1.0.pdf> than >> it is by UMA. I’m curious whether and how well UMA maps to any of the usage >> scenarios in that document, but that’s a thread that I’m going to choose >> not to tug on right now. >> >> I do agree that the RS enforces the access control policy because they >> serve up resources when the required permission tickets are presented. The >> AS absolutely has a role in enforcing an access control policy since they >> are responsible for serving up permission tickets only in accordance with >> the policy. Am I misunderstanding something? I have not found the “Adrian >> clause”, can you point me to it? >> >> Thanks and regards, >> Scott >> >> Scott Shorter - Vice President, Security >> sshorter(a)kimbleassociates.com >> >> On Jun 21, 2016, at 10:54 AM, Adrian Gropper <agropper(a)healthurl.com> >> wrote: >> >> Hi Scott, >> >> Thank you for highlighting a critical distinction between the AS as >> "trusted agent of the patient" and the AS "enforcer". This is a very >> helpful step to consensus. >> >> I maintain that the RS Is the only "enforcer" in the UMA model. Whatever >> the UMA AS says, the RS always has the last word and may override the AS to >> grant either more or less scope. (This kind is a foundational component of >> UMA as opposed to just OAuth, and is informally referred to in the guidance >> docs as "the Adrian clause".) >> >> I hope we can settle whether the AS is completely trusted by Alice or not >> as we continue this thread. >> >> Adrian >> >> On Tuesday, June 21, 2016, Scott Shorter <sshorter(a)kimbleassociates.com> >> wrote: >> >>> Hi Adrian, >>> >>> 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. >>> >>> >>> While I concur with the premise that HEART should not be profiling >>> privacy, I do not agree that that is what is currently being proposed. As >>> I mentioned on the call I believe the issue at hand is access control >>> rather than privacy. >>> >>> During today's HEART call we agreed that "Alice completely trusts her >>> UMA Authorization Server." >>> >>> >>> I believe that the proposed statement is incomplete until it specifies >>> *what* Alice “completely trusts” her AS *to do*. I suggest instead >>> that “Alice trusts her UMA Authorization Server to enforce the access >>> control policy.” Questions of specifically how to protect Alice’s >>> privacy using those access control settings are beyond the scope of the >>> profile, but discussion of how access control would be implemented in the >>> profile is quite appropriate. >>> >>> So the discussion is not about “profiling privacy” so much as >>> identifying the access control settings that make sense in the context of >>> the use case. Specifying that the AS is responsible for enforcing an >>> access control policy is well within the scope of defining a profile. It >>> also makes sense for a use case to specify that certain resources are >>> expected to be protected by default. >>> >>> I think we agree that the profile should not “profile privacy” by >>> specifying on Alice’s behalf what data may or may not be shared, but it >>> seems entirely in the scope of the effort to stipulate that the >>> Authorization Server will enforce Alice’s expected access control policy. >>> A specific use case can even describe the access control policies that are >>> assumed to be in place, and the ways that Alice might modify them, as a way >>> to illustrate the capabilities enabled by the profile. >>> >>> Thanks, >>> Scott >>> >>> Scott Shorter - Vice President, Security >>> sshorter(a)kimbleassociates.com >>> >> >> >> -- >> >> 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/ >> >> >> > > > -- > > 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/ > > > -- 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

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

22 Jun '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-23 *Date and Time* - *Thu Jun 23,* 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* - Roll call - Approve minutes of UMA telecon 2016-06-02 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-02> - MPD - Entertain any concrete spec proposals for already agreed-on changes for discovery document and phase 1 - Compare-and-contract exercise for MPD sequence diagram <http://www.websequencediagrams.com/files/render?link=2DdzslbnVj3ShhlrLVV-> and existing detailed sequence diagram <http://www.websequencediagrams.com/files/render?link=V0tZE2kWrO0l-tGlZX1a> (the latter doesn't call out specific AS endpoints, but could be made to) - Any further discussion/concrete proposals on client awareness of scopes? - Any further discussion/concrete proposals on registering multiple resource sets? - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 2

Re: [WG-UMA] Is HEART profiling privacy?
by Adrian Gropper 22 Jun '16

22 Jun '16

>From the Jan 29 minutes: The actual UMA Core spec has a clause, which Eve has dubbed the "Adrian clause": UMA Core Sec 3.3.3 <https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html#give-access>: "The resource server MAY apply additional authorization controls when determining how to respond." Adrian On Wed, Jun 22, 2016 at 10:31 AM, Scott Shorter < sshorter(a)kimbleassociates.com> wrote: > Hi Adrian, > > Thanks for clarifying the distinction. I just realized that my > understanding of the term authorization server is probably influenced more > by my familiarity with the 2005 common criteria protection profile > <https://www.commoncriteriaportal.org/files/ppfiles/PP_AUTHSRV_BR_v1.0.pdf> than > it is by UMA. I’m curious whether and how well UMA maps to any of the usage > scenarios in that document, but that’s a thread that I’m going to choose > not to tug on right now. > > I do agree that the RS enforces the access control policy because they > serve up resources when the required permission tickets are presented. The > AS absolutely has a role in enforcing an access control policy since they > are responsible for serving up permission tickets only in accordance with > the policy. Am I misunderstanding something? I have not found the “Adrian > clause”, can you point me to it? > > Thanks and regards, > Scott > > Scott Shorter - Vice President, Security > sshorter(a)kimbleassociates.com > > On Jun 21, 2016, at 10:54 AM, Adrian Gropper <agropper(a)healthurl.com> > wrote: > > Hi Scott, > > Thank you for highlighting a critical distinction between the AS as > "trusted agent of the patient" and the AS "enforcer". This is a very > helpful step to consensus. > > I maintain that the RS Is the only "enforcer" in the UMA model. Whatever > the UMA AS says, the RS always has the last word and may override the AS to > grant either more or less scope. (This kind is a foundational component of > UMA as opposed to just OAuth, and is informally referred to in the guidance > docs as "the Adrian clause".) > > I hope we can settle whether the AS is completely trusted by Alice or not > as we continue this thread. > > Adrian > > On Tuesday, June 21, 2016, Scott Shorter <sshorter(a)kimbleassociates.com> > wrote: > >> Hi Adrian, >> >> 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. >> >> >> While I concur with the premise that HEART should not be profiling >> privacy, I do not agree that that is what is currently being proposed. As >> I mentioned on the call I believe the issue at hand is access control >> rather than privacy. >> >> During today's HEART call we agreed that "Alice completely trusts her UMA >> Authorization Server." >> >> >> I believe that the proposed statement is incomplete until it specifies >> *what* Alice “completely trusts” her AS *to do*. I suggest instead that >> “Alice trusts her UMA Authorization Server to enforce the access control >> policy.” Questions of specifically how to protect Alice’s privacy using >> those access control settings are beyond the scope of the profile, but >> discussion of how access control would be implemented in the profile is >> quite appropriate. >> >> So the discussion is not about “profiling privacy” so much as identifying >> the access control settings that make sense in the context of the use case. >> Specifying that the AS is responsible for enforcing an access control >> policy is well within the scope of defining a profile. It also makes sense >> for a use case to specify that certain resources are expected to be >> protected by default. >> >> I think we agree that the profile should not “profile privacy” by >> specifying on Alice’s behalf what data may or may not be shared, but it >> seems entirely in the scope of the effort to stipulate that the >> Authorization Server will enforce Alice’s expected access control policy. >> A specific use case can even describe the access control policies that are >> assumed to be in place, and the ways that Alice might modify them, as a way >> to illustrate the capabilities enabled by the profile. >> >> Thanks, >> Scott >> >> Scott Shorter - Vice President, Security >> sshorter(a)kimbleassociates.com >> > > > -- > > 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/ > > > -- 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

Re: [WG-UMA] Is HEART profiling privacy?
by Adrian Gropper 21 Jun '16

21 Jun '16

Hi Scott, Thank you for highlighting a critical distinction between the AS as "trusted agent of the patient" and the AS "enforcer". This is a very helpful step to consensus. I maintain that the RS Is the only "enforcer" in the UMA model. Whatever the UMA AS says, the RS always has the last word and may override the AS to grant either more or less scope. (This kind is a foundational component of UMA as opposed to just OAuth, and is informally referred to in the guidance docs as "the Adrian clause".) I hope we can settle whether the AS is completely trusted by Alice or not as we continue this thread. Adrian On Tuesday, June 21, 2016, Scott Shorter <sshorter(a)kimbleassociates.com> wrote: > Hi Adrian, > > 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. > > > While I concur with the premise that HEART should not be profiling > privacy, I do not agree that that is what is currently being proposed. As > I mentioned on the call I believe the issue at hand is access control > rather than privacy. > > During today's HEART call we agreed that "Alice completely trusts her UMA > Authorization Server." > > > I believe that the proposed statement is incomplete until it specifies > *what* Alice “completely trusts” her AS *to do*. I suggest instead that > “Alice trusts her UMA Authorization Server to enforce the access control > policy.” Questions of specifically how to protect Alice’s privacy using > those access control settings are beyond the scope of the profile, but > discussion of how access control would be implemented in the profile is > quite appropriate. > > So the discussion is not about “profiling privacy” so much as identifying > the access control settings that make sense in the context of the use case. > Specifying that the AS is responsible for enforcing an access control > policy is well within the scope of defining a profile. It also makes sense > for a use case to specify that certain resources are expected to be > protected by default. > > I think we agree that the profile should not “profile privacy” by > specifying on Alice’s behalf what data may or may not be shared, but it > seems entirely in the scope of the effort to stipulate that the > Authorization Server will enforce Alice’s expected access control policy. > A specific use case can even describe the access control policies that are > assumed to be in place, and the ways that Alice might modify them, as a way > to illustrate the capabilities enabled by the profile. > > Thanks, > Scott > > Scott Shorter - Vice President, Security > sshorter(a)kimbleassociates.com > <javascript:_e(%7B%7D,'cvml','sshorter(a)kimbleassociates.com');> > -- 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

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