- WG-UMA - mailman.kantarainitiative.org

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

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