[legal] Newly revised versions of RSO - ASO model clauses, with questions/commentary
We agreed to start with the RSO - ASO trust relationship because it's most "upstream" and has no dependencies. It also turns out to be one of the most simple, at least in terms of previously brainstormed obligations/clauses. Below, I've taken the original obligations/duties and revised and commented on them given recent conversations. Let's discuss tomorrow. ==== *Condition applying to all:* For the period that the {Resource_Server_Operator} and {Authorization_Server_Operator} have mutually agreed to serve in these respective roles for each other… *Candidate duty A.* “RSO-Register-Accurately-and-Timely” …the RSO gains an obligation to the ASO to register resource set descriptions accurately and timely. Q A1. Do we have to qualify the wording above any further (given that we haven’t reached “Resource Subject/Grantor mention stage” yet) to talk about which resource set descriptions need to be registered? Note that there is no obligation for any RS to give any Grantor a choice about which resources to put under/take out of AS protection etc. It’s actually totally up to the RS. *Candidate duty B.* “RSO-Respect-Permissions” …the RSO gains an obligation to the ASO to respect the permissions that the AS associates with “bearer”-type RPTs when such RPTs are later borne to the RS by Clients. Q B1. This gets to the heart of our #RSctrl issue, as represented by the decision tree in these January meeting notes <http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes#UMAlegalsubgroupnotes-2016-01-15>. Do we need to rejigger this so that it is a) finer-grained and/or b) per-Resource Subject or on a case-by-case basis vs. per-ASO? Note that this a matter for ASO liability, as much as for Resource Subject concern, so this trust relationship does need to bear some of the weight. Much work to do here! Q B2. The “bearer”-type token profile is mentioned specifically because each token profile comes with its own distribution of policy decision-making responsibility between RS and AS. Does this make sense? *Candidate duty C.* “ASO-Elevate-Trust-Accurately” …the ASO gains an obligation to the RSO to perform trust elevation accurately and represent the results of trust elevation accurately in permissions in “bearer”-type RPTs. Q C1. This is the reciprocal liability duty that the ASO carries regarding the RSO. Does that make sense? ==== What other clauses might make sense to add? ==== The theory is that if we get the RSO - ASO clauses right, then these would all be prerequisite for the next two batches, Grantor - ASO and Grantor - RSO. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
Candidate duty D: "ASO-Provide-Notification-Endpoint" ...to enable the RSO to act in good faith when exceptions to Candidate Duty B are encountered in either Phase 1, 2, or 3 of UMA. Adrian On Fri, Apr 1, 2016 at 12:42 AM, Eve Maler <eve@xmlgrrl.com> wrote:
We agreed to start with the RSO - ASO trust relationship because it's most "upstream" and has no dependencies. It also turns out to be one of the most simple, at least in terms of previously brainstormed obligations/clauses. Below, I've taken the original obligations/duties and revised and commented on them given recent conversations. Let's discuss tomorrow.
====
*Condition applying to all:* For the period that the {Resource_Server_Operator} and {Authorization_Server_Operator} have mutually agreed to serve in these respective roles for each other…
*Candidate duty A.* “RSO-Register-Accurately-and-Timely” …the RSO gains an obligation to the ASO to register resource set descriptions accurately and timely.
Q A1. Do we have to qualify the wording above any further (given that we haven’t reached “Resource Subject/Grantor mention stage” yet) to talk about which resource set descriptions need to be registered? Note that there is no obligation for any RS to give any Grantor a choice about which resources to put under/take out of AS protection etc. It’s actually totally up to the RS.
*Candidate duty B.* “RSO-Respect-Permissions” …the RSO gains an obligation to the ASO to respect the permissions that the AS associates with “bearer”-type RPTs when such RPTs are later borne to the RS by Clients.
Q B1. This gets to the heart of our #RSctrl issue, as represented by the decision tree in these January meeting notes <http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes#UMAlegalsubgroupnotes-2016-01-15>. Do we need to rejigger this so that it is a) finer-grained and/or b) per-Resource Subject or on a case-by-case basis vs. per-ASO? Note that this a matter for ASO liability, as much as for Resource Subject concern, so this trust relationship does need to bear some of the weight. Much work to do here!
Q B2. The “bearer”-type token profile is mentioned specifically because each token profile comes with its own distribution of policy decision-making responsibility between RS and AS. Does this make sense?
*Candidate duty C.* “ASO-Elevate-Trust-Accurately” …the ASO gains an obligation to the RSO to perform trust elevation accurately and represent the results of trust elevation accurately in permissions in “bearer”-type RPTs.
Q C1. This is the reciprocal liability duty that the ASO carries regarding the RSO. Does that make sense?
====
What other clauses might make sense to add?
====
The theory is that if we get the RSO - ASO clauses right, then these would all be prerequisite for the next two batches, Grantor - ASO and Grantor - RSO.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
_______________________________________________ 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/
Regarding candidate duty D, I wonder if it might be better stated the other way around (it's the RSO that has the duty) until we have a technical endpoint available for the AS (or maybe someone else also/instead?) to expose. As noted under candidate duty B, rather than have the RSO "respect the permissions" 100%, more likely it would be something like the RSO has a matrix of duties that looks like our list from our Jan 15 meeting notes <http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes#UMAlegalsubgroupnotes-2016-01-15>, only with the conditions filled in, and with the method of notification hopefully prescribed in some fashion. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Fri, Apr 1, 2016 at 9:00 AM, Adrian Gropper <agropper@healthurl.com> wrote:
Candidate duty D: "ASO-Provide-Notification-Endpoint" ...to enable the RSO to act in good faith when exceptions to Candidate Duty B are encountered in either Phase 1, 2, or 3 of UMA.
Adrian
On Fri, Apr 1, 2016 at 12:42 AM, Eve Maler <eve@xmlgrrl.com> wrote:
We agreed to start with the RSO - ASO trust relationship because it's most "upstream" and has no dependencies. It also turns out to be one of the most simple, at least in terms of previously brainstormed obligations/clauses. Below, I've taken the original obligations/duties and revised and commented on them given recent conversations. Let's discuss tomorrow.
====
*Condition applying to all:* For the period that the {Resource_Server_Operator} and {Authorization_Server_Operator} have mutually agreed to serve in these respective roles for each other…
*Candidate duty A.* “RSO-Register-Accurately-and-Timely” …the RSO gains an obligation to the ASO to register resource set descriptions accurately and timely.
Q A1. Do we have to qualify the wording above any further (given that we haven’t reached “Resource Subject/Grantor mention stage” yet) to talk about which resource set descriptions need to be registered? Note that there is no obligation for any RS to give any Grantor a choice about which resources to put under/take out of AS protection etc. It’s actually totally up to the RS.
*Candidate duty B.* “RSO-Respect-Permissions” …the RSO gains an obligation to the ASO to respect the permissions that the AS associates with “bearer”-type RPTs when such RPTs are later borne to the RS by Clients.
Q B1. This gets to the heart of our #RSctrl issue, as represented by the decision tree in these January meeting notes <http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes#UMAlegalsubgroupnotes-2016-01-15>. Do we need to rejigger this so that it is a) finer-grained and/or b) per-Resource Subject or on a case-by-case basis vs. per-ASO? Note that this a matter for ASO liability, as much as for Resource Subject concern, so this trust relationship does need to bear some of the weight. Much work to do here!
Q B2. The “bearer”-type token profile is mentioned specifically because each token profile comes with its own distribution of policy decision-making responsibility between RS and AS. Does this make sense?
*Candidate duty C.* “ASO-Elevate-Trust-Accurately” …the ASO gains an obligation to the RSO to perform trust elevation accurately and represent the results of trust elevation accurately in permissions in “bearer”-type RPTs.
Q C1. This is the reciprocal liability duty that the ASO carries regarding the RSO. Does that make sense?
====
What other clauses might make sense to add?
====
The theory is that if we get the RSO - ASO clauses right, then these would all be prerequisite for the next two batches, Grantor - ASO and Grantor - RSO.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
_______________________________________________ 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/
Making it an ASO duty is critical to UMA adoption. If we don't provide the notification endpoint at the ASO, the RSO will simply ask for an email address or something and ignore UMA in favor of a tightly bound AS. This is the camel's nose under the tent because it's harder to block arbitrary notification endpoints than it is to block arbitrary authorization endpoints. In other words, I want my notifications sent to my technology even if you say I have no power to control authorization at all. Adrian On Tue, Apr 12, 2016 at 1:27 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Regarding candidate duty D, I wonder if it might be better stated the other way around (it's the RSO that has the duty) until we have a technical endpoint available for the AS (or maybe someone else also/instead?) to expose. As noted under candidate duty B, rather than have the RSO "respect the permissions" 100%, more likely it would be something like the RSO has a matrix of duties that looks like our list from our Jan 15 meeting notes <http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes#UMAlegalsubgroupnotes-2016-01-15>, only with the conditions filled in, and with the method of notification hopefully prescribed in some fashion.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Fri, Apr 1, 2016 at 9:00 AM, Adrian Gropper <agropper@healthurl.com> wrote:
Candidate duty D: "ASO-Provide-Notification-Endpoint" ...to enable the RSO to act in good faith when exceptions to Candidate Duty B are encountered in either Phase 1, 2, or 3 of UMA.
Adrian
On Fri, Apr 1, 2016 at 12:42 AM, Eve Maler <eve@xmlgrrl.com> wrote:
We agreed to start with the RSO - ASO trust relationship because it's most "upstream" and has no dependencies. It also turns out to be one of the most simple, at least in terms of previously brainstormed obligations/clauses. Below, I've taken the original obligations/duties and revised and commented on them given recent conversations. Let's discuss tomorrow.
====
*Condition applying to all:* For the period that the {Resource_Server_Operator} and {Authorization_Server_Operator} have mutually agreed to serve in these respective roles for each other…
*Candidate duty A.* “RSO-Register-Accurately-and-Timely” …the RSO gains an obligation to the ASO to register resource set descriptions accurately and timely.
Q A1. Do we have to qualify the wording above any further (given that we haven’t reached “Resource Subject/Grantor mention stage” yet) to talk about which resource set descriptions need to be registered? Note that there is no obligation for any RS to give any Grantor a choice about which resources to put under/take out of AS protection etc. It’s actually totally up to the RS.
*Candidate duty B.* “RSO-Respect-Permissions” …the RSO gains an obligation to the ASO to respect the permissions that the AS associates with “bearer”-type RPTs when such RPTs are later borne to the RS by Clients.
Q B1. This gets to the heart of our #RSctrl issue, as represented by the decision tree in these January meeting notes <http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes#UMAlegalsubgroupnotes-2016-01-15>. Do we need to rejigger this so that it is a) finer-grained and/or b) per-Resource Subject or on a case-by-case basis vs. per-ASO? Note that this a matter for ASO liability, as much as for Resource Subject concern, so this trust relationship does need to bear some of the weight. Much work to do here!
Q B2. The “bearer”-type token profile is mentioned specifically because each token profile comes with its own distribution of policy decision-making responsibility between RS and AS. Does this make sense?
*Candidate duty C.* “ASO-Elevate-Trust-Accurately” …the ASO gains an obligation to the RSO to perform trust elevation accurately and represent the results of trust elevation accurately in permissions in “bearer”-type RPTs.
Q C1. This is the reciprocal liability duty that the ASO carries regarding the RSO. Does that make sense?
====
What other clauses might make sense to add?
====
The theory is that if we get the RSO - ASO clauses right, then these would all be prerequisite for the next two batches, Grantor - ASO and Grantor - RSO.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
_______________________________________________ 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/
-- 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/
Your crystal ball about the ecosystem pressures may or may not be right... But "my technology" could include "my shoebox endpoint" even if it lives outside "my AS". It's not entirely clear yet that this endpoint (which doesn't exist yet) is part of an API that should inextricably be bound up with an UMA protection API vs. the API of some other kinds of service(s). FWIW, I get a ton of use out of registering one or more email addresses from/to which I can forward various kinds of invoices, receipts, and other artifacts; it works great with today's technology, and it doesn't seem to be "disempowering" (you can use it with IFTTT and other lightweight business process management "recipe" tech). Why couldn't email be one very successful design pattern for notification? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Tue, Apr 12, 2016 at 11:14 AM, Adrian Gropper <agropper@healthurl.com> wrote:
Making it an ASO duty is critical to UMA adoption. If we don't provide the notification endpoint at the ASO, the RSO will simply ask for an email address or something and ignore UMA in favor of a tightly bound AS. This is the camel's nose under the tent because it's harder to block arbitrary notification endpoints than it is to block arbitrary authorization endpoints. In other words, I want my notifications sent to my technology even if you say I have no power to control authorization at all.
Adrian
On Tue, Apr 12, 2016 at 1:27 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Regarding candidate duty D, I wonder if it might be better stated the other way around (it's the RSO that has the duty) until we have a technical endpoint available for the AS (or maybe someone else also/instead?) to expose. As noted under candidate duty B, rather than have the RSO "respect the permissions" 100%, more likely it would be something like the RSO has a matrix of duties that looks like our list from our Jan 15 meeting notes <http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes#UMAlegalsubgroupnotes-2016-01-15>, only with the conditions filled in, and with the method of notification hopefully prescribed in some fashion.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Fri, Apr 1, 2016 at 9:00 AM, Adrian Gropper <agropper@healthurl.com> wrote:
Candidate duty D: "ASO-Provide-Notification-Endpoint" ...to enable the RSO to act in good faith when exceptions to Candidate Duty B are encountered in either Phase 1, 2, or 3 of UMA.
Adrian
On Fri, Apr 1, 2016 at 12:42 AM, Eve Maler <eve@xmlgrrl.com> wrote:
We agreed to start with the RSO - ASO trust relationship because it's most "upstream" and has no dependencies. It also turns out to be one of the most simple, at least in terms of previously brainstormed obligations/clauses. Below, I've taken the original obligations/duties and revised and commented on them given recent conversations. Let's discuss tomorrow.
====
*Condition applying to all:* For the period that the {Resource_Server_Operator} and {Authorization_Server_Operator} have mutually agreed to serve in these respective roles for each other…
*Candidate duty A.* “RSO-Register-Accurately-and-Timely” …the RSO gains an obligation to the ASO to register resource set descriptions accurately and timely.
Q A1. Do we have to qualify the wording above any further (given that we haven’t reached “Resource Subject/Grantor mention stage” yet) to talk about which resource set descriptions need to be registered? Note that there is no obligation for any RS to give any Grantor a choice about which resources to put under/take out of AS protection etc. It’s actually totally up to the RS.
*Candidate duty B.* “RSO-Respect-Permissions” …the RSO gains an obligation to the ASO to respect the permissions that the AS associates with “bearer”-type RPTs when such RPTs are later borne to the RS by Clients.
Q B1. This gets to the heart of our #RSctrl issue, as represented by the decision tree in these January meeting notes <http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes#UMAlegalsubgroupnotes-2016-01-15>. Do we need to rejigger this so that it is a) finer-grained and/or b) per-Resource Subject or on a case-by-case basis vs. per-ASO? Note that this a matter for ASO liability, as much as for Resource Subject concern, so this trust relationship does need to bear some of the weight. Much work to do here!
Q B2. The “bearer”-type token profile is mentioned specifically because each token profile comes with its own distribution of policy decision-making responsibility between RS and AS. Does this make sense?
*Candidate duty C.* “ASO-Elevate-Trust-Accurately” …the ASO gains an obligation to the RSO to perform trust elevation accurately and represent the results of trust elevation accurately in permissions in “bearer”-type RPTs.
Q C1. This is the reciprocal liability duty that the ASO carries regarding the RSO. Does that make sense?
====
What other clauses might make sense to add?
====
The theory is that if we get the RSO - ASO clauses right, then these would all be prerequisite for the next two batches, Grantor - ASO and Grantor - RSO.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
_______________________________________________ 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/
--
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/
I'm not using a crystal ball. I just see UMA as delegation. By linking as many aspects of delegation as possible, we make delegation irresistible. Separating out notification form authorization, simply exposes on aspect of the ROs policies to the RS. By extension, we could start separating out other aspects of delegation such as which IDPs the AS will trust, or what jurisdiction the ASO is in, etc... As far as email address is concerned, I think it's an ideal way to discover my UMA AS using WebFinger but it should not be redundantly assumed to be my notification endpoint. Adrian On Tue, Apr 12, 2016 at 2:58 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Your crystal ball about the ecosystem pressures may or may not be right... But "my technology" could include "my shoebox endpoint" even if it lives outside "my AS". It's not entirely clear yet that this endpoint (which doesn't exist yet) is part of an API that should inextricably be bound up with an UMA protection API vs. the API of some other kinds of service(s).
FWIW, I get a ton of use out of registering one or more email addresses from/to which I can forward various kinds of invoices, receipts, and other artifacts; it works great with today's technology, and it doesn't seem to be "disempowering" (you can use it with IFTTT and other lightweight business process management "recipe" tech). Why couldn't email be one very successful design pattern for notification?
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Tue, Apr 12, 2016 at 11:14 AM, Adrian Gropper <agropper@healthurl.com> wrote:
Making it an ASO duty is critical to UMA adoption. If we don't provide the notification endpoint at the ASO, the RSO will simply ask for an email address or something and ignore UMA in favor of a tightly bound AS. This is the camel's nose under the tent because it's harder to block arbitrary notification endpoints than it is to block arbitrary authorization endpoints. In other words, I want my notifications sent to my technology even if you say I have no power to control authorization at all.
Adrian
On Tue, Apr 12, 2016 at 1:27 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Regarding candidate duty D, I wonder if it might be better stated the other way around (it's the RSO that has the duty) until we have a technical endpoint available for the AS (or maybe someone else also/instead?) to expose. As noted under candidate duty B, rather than have the RSO "respect the permissions" 100%, more likely it would be something like the RSO has a matrix of duties that looks like our list from our Jan 15 meeting notes <http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes#UMAlegalsubgroupnotes-2016-01-15>, only with the conditions filled in, and with the method of notification hopefully prescribed in some fashion.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Fri, Apr 1, 2016 at 9:00 AM, Adrian Gropper <agropper@healthurl.com> wrote:
Candidate duty D: "ASO-Provide-Notification-Endpoint" ...to enable the RSO to act in good faith when exceptions to Candidate Duty B are encountered in either Phase 1, 2, or 3 of UMA.
Adrian
On Fri, Apr 1, 2016 at 12:42 AM, Eve Maler <eve@xmlgrrl.com> wrote:
We agreed to start with the RSO - ASO trust relationship because it's most "upstream" and has no dependencies. It also turns out to be one of the most simple, at least in terms of previously brainstormed obligations/clauses. Below, I've taken the original obligations/duties and revised and commented on them given recent conversations. Let's discuss tomorrow.
====
*Condition applying to all:* For the period that the {Resource_Server_Operator} and {Authorization_Server_Operator} have mutually agreed to serve in these respective roles for each other…
*Candidate duty A.* “RSO-Register-Accurately-and-Timely” …the RSO gains an obligation to the ASO to register resource set descriptions accurately and timely.
Q A1. Do we have to qualify the wording above any further (given that we haven’t reached “Resource Subject/Grantor mention stage” yet) to talk about which resource set descriptions need to be registered? Note that there is no obligation for any RS to give any Grantor a choice about which resources to put under/take out of AS protection etc. It’s actually totally up to the RS.
*Candidate duty B.* “RSO-Respect-Permissions” …the RSO gains an obligation to the ASO to respect the permissions that the AS associates with “bearer”-type RPTs when such RPTs are later borne to the RS by Clients.
Q B1. This gets to the heart of our #RSctrl issue, as represented by the decision tree in these January meeting notes <http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes#UMAlegalsubgroupnotes-2016-01-15>. Do we need to rejigger this so that it is a) finer-grained and/or b) per-Resource Subject or on a case-by-case basis vs. per-ASO? Note that this a matter for ASO liability, as much as for Resource Subject concern, so this trust relationship does need to bear some of the weight. Much work to do here!
Q B2. The “bearer”-type token profile is mentioned specifically because each token profile comes with its own distribution of policy decision-making responsibility between RS and AS. Does this make sense?
*Candidate duty C.* “ASO-Elevate-Trust-Accurately” …the ASO gains an obligation to the RSO to perform trust elevation accurately and represent the results of trust elevation accurately in permissions in “bearer”-type RPTs.
Q C1. This is the reciprocal liability duty that the ASO carries regarding the RSO. Does that make sense?
====
What other clauses might make sense to add?
====
The theory is that if we get the RSO - ASO clauses right, then these would all be prerequisite for the next two batches, Grantor - ASO and Grantor - RSO.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
_______________________________________________ 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/
--
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/
participants (2)
-
Adrian Gropper -
Eve Maler