- WG-UMA - mailman.kantarainitiative.org

Agenda for UMA telecom 2016-06-30
by Eve Maler 29 Jun '16

29 Jun '16

(Try the web calling interface this time if the other calling methods give you trouble...) http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-30 Date and Time - *Thu Jun 30,* 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 178-2540# - Screen sharing: http://join.me/findthomas - *NOTE:* *IGNORE* the join.me dial-in line - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar - If our TurboBridge troubles persist, we'll consider moving to a donated bridge Agenda - Roll call - Approve minutes of UMA telecom 2016-06-23 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-23> - 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> - Registering multiple resource sets - Input from George on existing spec text? - Client awareness of scopes - Concrete proposals based on multiple-resource-set directions? - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Token-first, reduced-ticket use flow
by James Phillpotts 27 Jun '16

27 Jun '16

Hi all, I'd like to formally propose support for a token-first, reduced-ticket use flow for UMA-next. The scenario this addresses is when the RS publicly publishes the scopes that it uses for resources (as many OAuth2 RSs do currently), and the Client would like to get a single token for this up-front, before it accesses anything at the RS specifically owned by Alice. Here is a brief description of how I see this working: - For the simple case, let's say that Client service is a tightly coupled client to services from one RS (could be multiple, not necessary for this description). Let's say the RS is a photo sharing site, and the Client is a photo printing site - Bob signs up to Printing (client) service - Client uses AS for sign in - Because the Client knows that the user will be printing photos, it requests scope photos-view-hires in its token - Client has obtained access token that includes the requested scope - Client accesses Alice's photo resource, presenting Bob's bearer token - RS uses the protection API to register an attempted access to a Resource Set, but includes the presented token in the request - The AS evaluates the policy for the Resource Set using the details from the token, and responds: - If the policy is satisfied, (a) a ticket is not generated, and the AS returns a success response - If the policy is not satisfied, the AS can choose whether (b) to return a ticket, in which case the UMA flow continues as usual, or (c) return a forbidden response with optional message for Bob - The RS then returns either (a) the resource, (b) returns a WWW-Authenticate response, as per usual flow, or (c) returns a forbidden response with the message from the AS, if supplied. If it would help, I'm happy to produce a sequence diagram for the above. Cheers James

4 9

Really scary Microsoft Word and Dropbox experience
by Adrian Gropper 25 Jun '16

25 Jun '16

(apologies for cross-posting) I just created a shared folder with a vendor in my Dropbox and was notified by Dropbox of the change by email. I went to my Dropbox account settings to check on the scope of sharing that the new vendor just got and was surprised to see that Microsoft Word already had full access to read and write all of my Dropbox. I'm pretty careful about these things and I don't recall ever, for any reason, connecting Word and Dropbox. I assume that I did and just forgot but this kind of thing blows my mind. My point is simply that scattering my OAuth2-type authorization policies across multiple portals (and multiple OAuth2 Authorization Servers) is completely un-scalable. The model for policy management relative to either VRM or UMA has to be that each person gets to specify their policy server and notification endpoint to the various vendors. 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

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

24 Jun '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2016-06-24 - Review document deliverables - UMA Legal Primer <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…> - UMA Legal Use Cases Attending: Eve, Kathleen, Ann, John W, Adrian, Scott, Paul, Mark We started reviewing the primer. If we can't make it all fit into 2-3 pages as we first hoped, let's try and use a "progressive disclosure" approach, so that the first part boils down the rest of the paper in a very short space. *NOTE:* All but Eve (and John): Eve will "take the pen" over the weekend in the doc. If you want to do stuff in the doc till the next meeting, please do so in Suggest mode! Adrian introduced the notion of the AS as the only safe way to handle bots (such as Siri) that are the alternative to the explosion of apps on mobile devices (see the de-app-ification trend <http://www.wired.com/2015/06/apple-google-ecosystem/>). So the "agent" theme as exemplified by a *personal* AS could be an exploratory theme in the doc. How deep to go on privacy compliance? Scott suggests that UMA makes the underlying systems reliable and predictable, which provides a basis for trust and enables observability of regular actions. The systems are tuned to local expectations. Things are "done to spec". Adrian observes that UMA could be said to be a "core component of privacy engineering <https://en.wikipedia.org/wiki/Privacy_engineering>". Scott also reframes as "operational privacy". Don't forget about Privacy by Design <https://www.ipc.on.ca/english/privacy/introduction-to-pbd/> – here is the (old by now?) paper on Privacy by Design implications of UMA <http://tinyurl.com/umapbd>. Why could an XXX love it? CPO: - Standards make for cheaper solutions for compliance. Average US privacy budget (PSR '15): $300K. - Emerging ecology of user control standards gives an alternative to contracts of adhesion. Data subject: - There's power in having more "consent tech" solutions available and deployed on your behalf to choose from. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

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