AI: Adrian: Write up ROI form concerns wrt to UMA phase 1 implications for the group's consideration. [Legal]
- Definitions: *Resource Registration Agreement* - A contract between the Resource Server Operator and the resource subject or authorized agent of the resource subject that defines a resource pertaining to the resource subject, including available and supported scopes, and delegates some control over that resource to an Authorization Server. The Resource Registration Agreement establishes Phase 1 of the UMA Protocol at a time when neither the Client nor the Requesting Party are known to either the RS / RSO or the AS / ASO. As such, this is equivalent to a typical healthcare ROI form if the ROI form were to *specify an agent for the subject instead of the client* for for the purpose of authorized access to the resource. *Authorization Server Endpoint* - The URI and associated .well_known endpoints of a standards-based authorization server acting as the agent of the resource subject during UMA Phase 2. Under this Resource Registration Agreement, the RSO agrees to consider a token signed by the AS as presented by the RqP / Client. The RS may either accept the token or it can notify the AS that the token was not accepted or modified in scope. *Resource Subject Signature and Date* - The individual who's PII is accessed via the resource. This individual could be any age and should not need to be able to read or write or use technology. *Authorized Agent Name, Signature and Date* - The individual that the RSO recognizes as an authorized agent of the resource subject in cases where the resource subject is unable to sign for herself. The basis of this recognition is completely out of band from UMA. - Is this UMA? In my subject-centered vision of UMA, the RS has no visibility into whether the Resource Subject or the Authorized Agent or anyone else is in control of the Authorization Server Endpoint. In Phase 2 or 3 of UMA, the RS can choose to take attributes of the Client and RqP into consideration along with the Token issues by the AS or the RS can accept the token as is. If the RS changes the intent of the token, either more or fewer privileges, then the RS must notify the AS of the change. It may be that my subject-centered vision of UMA is not actually UMA. I don't know. If it's not, then we should try to give it a name because all I'm talking about is the subject's right to specify an agent by executing a Resource Registration Agreement - period. 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/
The definitions, with defined terms in them drawn from the UMA core. http://www.commonaccord.org/index.php?action=doc&file=S/Sandbox/AGropper/Definitions_0.md On Fri, Feb 12, 2016 at 11:56 PM, Adrian Gropper <agropper@healthurl.com> wrote:
- Definitions:
*Resource Registration Agreement* - A contract between the Resource Server Operator and the resource subject or authorized agent of the resource subject that defines a resource pertaining to the resource subject, including available and supported scopes, and delegates some control over that resource to an Authorization Server. The Resource Registration Agreement establishes Phase 1 of the UMA Protocol at a time when neither the Client nor the Requesting Party are known to either the RS / RSO or the AS / ASO. As such, this is equivalent to a typical healthcare ROI form if the ROI form were to *specify an agent for the subject instead of the client* for for the purpose of authorized access to the resource.
*Authorization Server Endpoint* - The URI and associated .well_known endpoints of a standards-based authorization server acting as the agent of the resource subject during UMA Phase 2. Under this Resource Registration Agreement, the RSO agrees to consider a token signed by the AS as presented by the RqP / Client. The RS may either accept the token or it can notify the AS that the token was not accepted or modified in scope.
*Resource Subject Signature and Date* - The individual who's PII is accessed via the resource. This individual could be any age and should not need to be able to read or write or use technology.
*Authorized Agent Name, Signature and Date* - The individual that the RSO recognizes as an authorized agent of the resource subject in cases where the resource subject is unable to sign for herself. The basis of this recognition is completely out of band from UMA.
- Is this UMA?
In my subject-centered vision of UMA, the RS has no visibility into whether the Resource Subject or the Authorized Agent or anyone else is in control of the Authorization Server Endpoint. In Phase 2 or 3 of UMA, the RS can choose to take attributes of the Client and RqP into consideration along with the Token issues by the AS or the RS can accept the token as is. If the RS changes the intent of the token, either more or fewer privileges, then the RS must notify the AS of the change.
It may be that my subject-centered vision of UMA is not actually UMA. I don't know. If it's not, then we should try to give it a name because all I'm talking about is the subject's right to specify an agent by executing a Resource Registration Agreement - period.
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/
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
-- @commonaccord
Below... *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Fri, Feb 12, 2016 at 2:56 PM, Adrian Gropper <agropper@healthurl.com> wrote:
- Definitions:
*Resource Registration Agreement* - A contract between the Resource Server Operator and the resource subject or authorized agent of the resource subject that defines a resource pertaining to the resource subject, including available and supported scopes, and delegates some control over that resource to an Authorization Server. The Resource Registration Agreement establishes Phase 1 of the UMA Protocol at a time when neither the Client nor the Requesting Party are known to either the RS / RSO or the AS / ASO. As such, this is equivalent to a typical healthcare ROI form if the ROI form were to *specify an agent for the subject instead of the client* for for the purpose of authorized access to the resource.
This looks just about exactly like what we've been categorizing as the Resource Server Operator's aggregate set of obligations to the Authorizing Party so far, both in the old Binding Obligations spec (where the latest possible "tripping event" was PAT issuance) and in our nascent model clause work, with one big clarification. We've been saying that the RSO would make these promises *generically* to the Authorizing Party. You're suggesting that the Authorizing Party explicitly needs to either *be* the Resource Subject or *acting on their behalf*. (Did you mean to say "*an agent for the subject instead of the subject*"? Otherwise, I'm confused.) (I think you're overcooking some of the details here, btw. Phase 1 is certainly before a client or requesting party *is required to be* in the picture, technically speaking, but of course Clients and Requesting Parties may already be known to these other parties.) (You are using "Resource Subject" below to mean something equivalent to "Data Subject" or "PII Subject", but haven't defined it apart from a longer term. Do we care which we use? What is going to be friendlier to the purposes of our customers? If it's six of one and half a dozen of another, it might actually be easiest to use this third-way term, because we can use it freely in our own UMA-related definitions, and then define the term by referencing the other two terms of art, mentioning their standards origin -- in other words, have as clean an interface between the UMA terminology world and the "outside" terminology world as possible. So for now, I've stuck with Resource Subject.)
*Authorization Server Endpoint* - The URI and associated .well_known endpoints of a standards-based authorization server acting as the agent of the resource subject during UMA Phase 2. Under this Resource Registration Agreement, the RSO agrees to consider a token signed by the AS as presented by the RqP / Client. The RS may either accept the token or it can notify the AS that the token was not accepted or modified in scope.
The endpoint description goes off the rails technically here, a bit. I don't think it's too useful to define technical stuff in a legal discussion; more important to focus on the legal distinctions. Here is the question I have regarding your ROI form concerns: - Are you proposing that a different Person interact with the authorization server and the resource server, so that one can be the Authorizing Party and the other can be the Resource Subject, respectively? *Resource Subject Signature and Date* - The individual who's PII is
accessed via the resource. This individual could be any age and should not need to be able to read or write or use technology.
And here's the next question I have regarding your ROI form concerns: - What if the Resource Subject does not have legal capacity to sign and date a form? (aha, but I think I see where you're going in the next step...) *Authorized Agent Name, Signature and Date* - The individual that the RSO
recognizes as an authorized agent of the resource subject in cases where the resource subject is unable to sign for herself. The basis of this recognition is completely out of band from UMA.
- So if the Resource Subject does not have legal capacity, then the you're saying the Authorized Agent would become the Authorizing Party on their behalf. I agree that the basis of this recognition is a BLT thing and not part of UMA-the-protocol.
- Is this UMA?
In my subject-centered vision of UMA, the RS has no visibility into whether the Resource Subject or the Authorized Agent or anyone else is in control of the Authorization Server Endpoint. In Phase 2 or 3 of UMA, the RS can choose to take attributes of the Client and RqP into consideration along with the Token issues by the AS or the RS can accept the token as is. If the RS changes the intent of the token, either more or fewer privileges, then the RS must notify the AS of the change.
It may be that my subject-centered vision of UMA is not actually UMA. I don't know. If it's not, then we should try to give it a name because all I'm talking about is the subject's right to specify an agent by executing a Resource Registration Agreement - period.
UMA-the-protocol does not care whether the resources being protected even contain PII. :-) The resources could be sensitive by virtue of being valuable (someone wants to charge for them or someone considers them trade secrets, or whatever). But if they are both sensitive and personal, we have treated it as an important UMA use case -- if not the only UMA use case -- that the resource owner/Authorizing Party is the Resource Subject. So it's a very very good idea for our work in this subgroup to focus first and foremost on model definitions and model clauses that get this right. This discussion is helping me get some of the use cases (or are they UMA design patterns?) swirling in my head into some kind of order. Let me try them in the attached graphic.... I've highlighted a few technical challenges there. We also have some legal definitional challenges remaining, like maybe: Authorizing Party Agent? What else?
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/
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
Sorry, my design patterns might have been a little too light on detail. Here are "user stories" that go with them: - - *Alice uses AS and RS for herself:* She's the Authorizing Party and also the Resource Subject. She would be the one using the AS to configure who gets access, and the one using the RS to manage resources. This is sort of "normal UMA" usage. - - *Alice uses AS and RS as agent for son Johnny:* Johnny is two years old, and he doesn't use any online services at all yet. Alice is his mom, and she manages his health data and daycare appointments as online resources. She is his legal agent because he doesn't have legal capacity. Technical challenges: Someday he'll get older and start managing resources on his own behalf. How does that transition of resources and accounts get effected? - - *Alice uses AS as agent for 12yo Susie; Susie uses RS herself:* Susie is an older kid, but still covered under laws such as COPPA, so she doesn't have the legal capacity to consent for herself. She logs into a resource server such as an UMA-enabled webkinz.com to manage her resources, but her mom Alice is the one who logs in to the authorization server to manage access settings for her as her agent. (For a long time, we have called this a "split-RO" pattern in the WG.) ... We haven't actually figured out how to make this happen 100%, though, because if you think about the OAuth flow to issue the PAT, it counts on a singular resource owner being on both sides, and here we have two people. The actual webkinz service does require parents to have a companion account, I think, so maybe that's something we assume? (Steve G.? Are you out there?) Also, when Susie gets old enough to have legal capacity (or meets other non-age tests), how do we manage that? - - *Gov agency/admin uses AS and RS as agent for citizen Alice:* As described on the last call, the NZ government did a proof-of-concept where they let an offline adult (who has legal capacity) set up a policy to share resources with somebody like a caregiver, or an adult son. While the caregiver etc. would be a requesting party, the *government agency itself* (or a human admin working as an employee of the agency -- holy recursion, Batman) is the agent of Alice in setting up a "headless" account for her, and manages it for her on an ongoing basis. Alice is sent an email when this happens, and can "claim" control of the RO account anytime she likes. You can read a brief description about it in the PDF file linked from here <http://kantarainitiative.org/confluence/display/uma/Case+Study%3A+Users+Managing+Delegated+Access+to+Online+Government+Services> (search for "headless"). I hope that last one is clear. I see now how Adrian and I might have been confusing each other. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Mon, Feb 15, 2016 at 8:21 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Below...
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Fri, Feb 12, 2016 at 2:56 PM, Adrian Gropper <agropper@healthurl.com> wrote:
- Definitions:
*Resource Registration Agreement* - A contract between the Resource Server Operator and the resource subject or authorized agent of the resource subject that defines a resource pertaining to the resource subject, including available and supported scopes, and delegates some control over that resource to an Authorization Server. The Resource Registration Agreement establishes Phase 1 of the UMA Protocol at a time when neither the Client nor the Requesting Party are known to either the RS / RSO or the AS / ASO. As such, this is equivalent to a typical healthcare ROI form if the ROI form were to *specify an agent for the subject instead of the client* for for the purpose of authorized access to the resource.
This looks just about exactly like what we've been categorizing as the Resource Server Operator's aggregate set of obligations to the Authorizing Party so far, both in the old Binding Obligations spec (where the latest possible "tripping event" was PAT issuance) and in our nascent model clause work, with one big clarification. We've been saying that the RSO would make these promises *generically* to the Authorizing Party. You're suggesting that the Authorizing Party explicitly needs to either *be* the Resource Subject or *acting on their behalf*.
(Did you mean to say "*an agent for the subject instead of the subject*"? Otherwise, I'm confused.)
(I think you're overcooking some of the details here, btw. Phase 1 is certainly before a client or requesting party *is required to be* in the picture, technically speaking, but of course Clients and Requesting Parties may already be known to these other parties.)
(You are using "Resource Subject" below to mean something equivalent to "Data Subject" or "PII Subject", but haven't defined it apart from a longer term. Do we care which we use? What is going to be friendlier to the purposes of our customers? If it's six of one and half a dozen of another, it might actually be easiest to use this third-way term, because we can use it freely in our own UMA-related definitions, and then define the term by referencing the other two terms of art, mentioning their standards origin -- in other words, have as clean an interface between the UMA terminology world and the "outside" terminology world as possible. So for now, I've stuck with Resource Subject.)
*Authorization Server Endpoint* - The URI and associated .well_known endpoints of a standards-based authorization server acting as the agent of the resource subject during UMA Phase 2. Under this Resource Registration Agreement, the RSO agrees to consider a token signed by the AS as presented by the RqP / Client. The RS may either accept the token or it can notify the AS that the token was not accepted or modified in scope.
The endpoint description goes off the rails technically here, a bit. I don't think it's too useful to define technical stuff in a legal discussion; more important to focus on the legal distinctions. Here is the question I have regarding your ROI form concerns:
- Are you proposing that a different Person interact with the authorization server and the resource server, so that one can be the Authorizing Party and the other can be the Resource Subject, respectively?
*Resource Subject Signature and Date* - The individual who's PII is
accessed via the resource. This individual could be any age and should not need to be able to read or write or use technology.
And here's the next question I have regarding your ROI form concerns:
- What if the Resource Subject does not have legal capacity to sign and date a form? (aha, but I think I see where you're going in the next step...)
*Authorized Agent Name, Signature and Date* - The individual that the RSO
recognizes as an authorized agent of the resource subject in cases where the resource subject is unable to sign for herself. The basis of this recognition is completely out of band from UMA.
- So if the Resource Subject does not have legal capacity, then the you're saying the Authorized Agent would become the Authorizing Party on their behalf. I agree that the basis of this recognition is a BLT thing and not part of UMA-the-protocol.
- Is this UMA?
In my subject-centered vision of UMA, the RS has no visibility into whether the Resource Subject or the Authorized Agent or anyone else is in control of the Authorization Server Endpoint. In Phase 2 or 3 of UMA, the RS can choose to take attributes of the Client and RqP into consideration along with the Token issues by the AS or the RS can accept the token as is. If the RS changes the intent of the token, either more or fewer privileges, then the RS must notify the AS of the change.
It may be that my subject-centered vision of UMA is not actually UMA. I don't know. If it's not, then we should try to give it a name because all I'm talking about is the subject's right to specify an agent by executing a Resource Registration Agreement - period.
UMA-the-protocol does not care whether the resources being protected even contain PII. :-) The resources could be sensitive by virtue of being valuable (someone wants to charge for them or someone considers them trade secrets, or whatever). But if they are both sensitive and personal, we have treated it as an important UMA use case -- if not the only UMA use case -- that the resource owner/Authorizing Party is the Resource Subject. So it's a very very good idea for our work in this subgroup to focus first and foremost on model definitions and model clauses that get this right.
This discussion is helping me get some of the use cases (or are they UMA design patterns?) swirling in my head into some kind of order. Let me try them in the attached graphic.... I've highlighted a few technical challenges there. We also have some legal definitional challenges remaining, like maybe: Authorizing Party Agent? What else?
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/
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
Eve and all, For the purposes of this thread I'm concerned about clarifying UMA (the protocol) as enabling (technological) agency for the [ Resource or PII Subject, I don't see the difference ] - and to also support delegation for those cases where the subject is incompetent in some way. My focus is only Phase 1, a time when the client is, not known to either the RS or the AS. Just because the client could sometimes be known at Phase 1 does not need to change the simplicity of the Resource Registration Agreement (RRA). Therefore, I want to avoid any mention of the client in the Resource Registration Agreement. This is why the RRA is different from a typical ROI form. The ROI form is a release of information to a specified client whereas the RRA is a delegation of authority to an agent of the Resource Subject. The policies of the agent, the UMA AS, including its authorized managers are to be opaque to the RS and revealed only as specifically declared in tokens pertaining to a specific client / RqP in Phase 2. This strong definition of agency makes it much easier to understand UMA in both the technical and legal sense. The definitions I suggested make clear that the Resource Subject and the Authorized Agent have separate identities relative to the RS and RSO. These separate identities are both captured in the RRA. The fact that both the Resource Subject and the Authorized Agent can have a direct relationship with the RS has nothing much to do with UMA (the protocol). As long as the RRA stands, the AS can provide its opinion about a particular client transaction through the associated Phase 2 token(s) and the RS is expected to act in good faith. Obviously, the Resource Subject, the Authorized Agent, or a Court can always interact directly with the RS to modify or revoke the RRA. By definition, since the RRA does nothing more than point to an AS, this merely replaces the AS with another AS or disconnects the resource from UMA (the protocol). In conclusion, I see no reason to worry about the four design patterns because only two things can happen: (a) If the Resource Subject, Authorized Agent, or Court act directly a the RS to modify the RRA, then the AS is hosed. (b) If the definition of UMA is based on strict agency and delegation to the AS (as described at the top of this response) then any action of the Resource Subject, Authorized Agent, or Court on the AS would be invisible as such to the RS because the RS sees only a token with scopes applicable to that transaction and no specific information about the AS policies or its managers. Adrian On Mon, Feb 15, 2016 at 11:47 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Sorry, my design patterns might have been a little too light on detail. Here are "user stories" that go with them:
- - *Alice uses AS and RS for herself:* She's the Authorizing Party and also the Resource Subject. She would be the one using the AS to configure who gets access, and the one using the RS to manage resources. This is sort of "normal UMA" usage. - - *Alice uses AS and RS as agent for son Johnny:* Johnny is two years old, and he doesn't use any online services at all yet. Alice is his mom, and she manages his health data and daycare appointments as online resources. She is his legal agent because he doesn't have legal capacity. Technical challenges: Someday he'll get older and start managing resources on his own behalf. How does that transition of resources and accounts get effected? - - *Alice uses AS as agent for 12yo Susie; Susie uses RS herself:* Susie is an older kid, but still covered under laws such as COPPA, so she doesn't have the legal capacity to consent for herself. She logs into a resource server such as an UMA-enabled webkinz.com to manage her resources, but her mom Alice is the one who logs in to the authorization server to manage access settings for her as her agent. (For a long time, we have called this a "split-RO" pattern in the WG.) ... We haven't actually figured out how to make this happen 100%, though, because if you think about the OAuth flow to issue the PAT, it counts on a singular resource owner being on both sides, and here we have two people. The actual webkinz service does require parents to have a companion account, I think, so maybe that's something we assume? (Steve G.? Are you out there?) Also, when Susie gets old enough to have legal capacity (or meets other non-age tests), how do we manage that? - - *Gov agency/admin uses AS and RS as agent for citizen Alice:* As described on the last call, the NZ government did a proof-of-concept where they let an offline adult (who has legal capacity) set up a policy to share resources with somebody like a caregiver, or an adult son. While the caregiver etc. would be a requesting party, the *government agency itself* (or a human admin working as an employee of the agency -- holy recursion, Batman) is the agent of Alice in setting up a "headless" account for her, and manages it for her on an ongoing basis. Alice is sent an email when this happens, and can "claim" control of the RO account anytime she likes. You can read a brief description about it in the PDF file linked from here <http://kantarainitiative.org/confluence/display/uma/Case+Study%3A+Users+Managing+Delegated+Access+to+Online+Government+Services> (search for "headless").
I hope that last one is clear. I see now how Adrian and I might have been confusing each other.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Mon, Feb 15, 2016 at 8:21 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Below...
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Fri, Feb 12, 2016 at 2:56 PM, Adrian Gropper <agropper@healthurl.com> wrote:
- Definitions:
*Resource Registration Agreement* - A contract between the Resource Server Operator and the resource subject or authorized agent of the resource subject that defines a resource pertaining to the resource subject, including available and supported scopes, and delegates some control over that resource to an Authorization Server. The Resource Registration Agreement establishes Phase 1 of the UMA Protocol at a time when neither the Client nor the Requesting Party are known to either the RS / RSO or the AS / ASO. As such, this is equivalent to a typical healthcare ROI form if the ROI form were to *specify an agent for the subject instead of the client* for for the purpose of authorized access to the resource.
This looks just about exactly like what we've been categorizing as the Resource Server Operator's aggregate set of obligations to the Authorizing Party so far, both in the old Binding Obligations spec (where the latest possible "tripping event" was PAT issuance) and in our nascent model clause work, with one big clarification. We've been saying that the RSO would make these promises *generically* to the Authorizing Party. You're suggesting that the Authorizing Party explicitly needs to either *be* the Resource Subject or *acting on their behalf*.
(Did you mean to say "*an agent for the subject instead of the subject*"? Otherwise, I'm confused.)
(I think you're overcooking some of the details here, btw. Phase 1 is certainly before a client or requesting party *is required to be* in the picture, technically speaking, but of course Clients and Requesting Parties may already be known to these other parties.)
(You are using "Resource Subject" below to mean something equivalent to "Data Subject" or "PII Subject", but haven't defined it apart from a longer term. Do we care which we use? What is going to be friendlier to the purposes of our customers? If it's six of one and half a dozen of another, it might actually be easiest to use this third-way term, because we can use it freely in our own UMA-related definitions, and then define the term by referencing the other two terms of art, mentioning their standards origin -- in other words, have as clean an interface between the UMA terminology world and the "outside" terminology world as possible. So for now, I've stuck with Resource Subject.)
*Authorization Server Endpoint* - The URI and associated .well_known endpoints of a standards-based authorization server acting as the agent of the resource subject during UMA Phase 2. Under this Resource Registration Agreement, the RSO agrees to consider a token signed by the AS as presented by the RqP / Client. The RS may either accept the token or it can notify the AS that the token was not accepted or modified in scope.
The endpoint description goes off the rails technically here, a bit. I don't think it's too useful to define technical stuff in a legal discussion; more important to focus on the legal distinctions. Here is the question I have regarding your ROI form concerns:
- Are you proposing that a different Person interact with the authorization server and the resource server, so that one can be the Authorizing Party and the other can be the Resource Subject, respectively?
*Resource Subject Signature and Date* - The individual who's PII is
accessed via the resource. This individual could be any age and should not need to be able to read or write or use technology.
And here's the next question I have regarding your ROI form concerns:
- What if the Resource Subject does not have legal capacity to sign and date a form? (aha, but I think I see where you're going in the next step...)
*Authorized Agent Name, Signature and Date* - The individual that the
RSO recognizes as an authorized agent of the resource subject in cases where the resource subject is unable to sign for herself. The basis of this recognition is completely out of band from UMA.
- So if the Resource Subject does not have legal capacity, then the you're saying the Authorized Agent would become the Authorizing Party on their behalf. I agree that the basis of this recognition is a BLT thing and not part of UMA-the-protocol.
- Is this UMA?
In my subject-centered vision of UMA, the RS has no visibility into whether the Resource Subject or the Authorized Agent or anyone else is in control of the Authorization Server Endpoint. In Phase 2 or 3 of UMA, the RS can choose to take attributes of the Client and RqP into consideration along with the Token issues by the AS or the RS can accept the token as is. If the RS changes the intent of the token, either more or fewer privileges, then the RS must notify the AS of the change.
It may be that my subject-centered vision of UMA is not actually UMA. I don't know. If it's not, then we should try to give it a name because all I'm talking about is the subject's right to specify an agent by executing a Resource Registration Agreement - period.
UMA-the-protocol does not care whether the resources being protected even contain PII. :-) The resources could be sensitive by virtue of being valuable (someone wants to charge for them or someone considers them trade secrets, or whatever). But if they are both sensitive and personal, we have treated it as an important UMA use case -- if not the only UMA use case -- that the resource owner/Authorizing Party is the Resource Subject. So it's a very very good idea for our work in this subgroup to focus first and foremost on model definitions and model clauses that get this right.
This discussion is helping me get some of the use cases (or are they UMA design patterns?) swirling in my head into some kind of order. Let me try them in the attached graphic.... I've highlighted a few technical challenges there. We also have some legal definitional challenges remaining, like maybe: Authorizing Party Agent? What else?
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/
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
-- 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/
participants (3)
-
Adrian Gropper -
Eve Maler -
James Hazard