[WG-UMA] Notes from UMA legal telecon 2016-02-19

[Eve Maler]

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes

2016-02-19

• Distinguishing resource subjects from resource owners: Can we develop a cohesive system whereby "resource subjects" without legal capacity can have "authorized agents" acting on their behalf as "resource owners" as required in order to forge "resource registration agreements" for the purpose of UMA's phase 1 particulars? Do the use cases/design patterns provide any insights or challenges here?
  • See email thread

Attending: Eve, Andrew Hughes, Paul L, John, Ann, Adrian, Jon, Kathleen, Sal

Is it valuable to solve for a model where an agent can be working on behalf of resource owner vs. a resource owner?

The protean nature of the word "agent/agency" is troubling. Is there a good substitute word? If not, do we have to define *Agent for all of our terms in an UMA context? We did already have Requesting Party Agent. Perhaps, at best, we should define it operationally but stay away from legal subtleties.

We've said that resource owner = Authorizing Party. Does that work, or is it not equivalent? There are terminology questions and there are UMA architecture questions. Should we just wave away problems by making them equivalent?

• 1yo case: What if the "resource owner" (let's say they're the "subject" of the data residing in the RS) is a one-year-old kid and their mom has to manage the resources by logging in to the RS? The child is not competent to contract, even if they're old enough to sign their name. Guardian is a good name for the latter.
• 12yo case: What if the "resource owner" (let's say they're the "subject" of the data residing in the RS) is a 12-year-old kid and they're old enough to manage the resources by logging in to the RS themselves? The child is not competent to contract, even if they're old enough to manage resources online. How to architect the system and name the parties?
• Intermittently competent adult case: This is another tough one.
• Competent adult case: What if the "resource owner" (let's say again that they're the "subject" of the data residing in the RS) is actually competent to contract, but wants to have someone else manage resources for them online? There's a paper resource owner, but an online "executor" of resource management. What's a good term?
• Digital death case: After the "resource owner"...

Adrian's concern is what happens in phase 1. These use cases have different properties in that phase. Eventually (soon), we will be in a position to work on what's supposed to happen when RS's want to take an action in response to an access request that is in contradiction to the permissions contained in an RPT (requesting party token). First, we need to understand exactly "who" configured the AS to 

By the way, all the same patterns could apply whether or not the resources contain PII or not. What if the resource owner created digital media that they want to sell? Is there a reason to distinguish in our terminology at all? What if a resource contains PII "in bulk" for many individuals (in directories or databases or other repositories)? This was the point of Adrian's example. Eve's point was, rather, that individuals might want to be protecting resources that don't contain PII. Okay, now we're on the same page! There are use cases for UMA that span "Alice" and "enterprise".

Let's try to conclude this decision-making process by next week, and then move on to the decisions about RS actions in contradiction.

Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

[Adrian Gropper]

"It's turtles all the way down, madam."

I'm not saying Eve is the madam. What I am saying is that the ISO concepts of Subject, Controller, and Processor are of limited utility to UMA technical or legal. As long as in real life the RS has a _direct_ relationship with the Subject (and the subject's custodian in Eve's five bullets above - whoever they are, they have credentials that the RS recognizes) the RS is both a Controller and a Processor. For example, a subject or custodian can present to the RS and nullify or amend the resource registration agreement representing UMA Phase 1. With the right credentials, the AS may not even be notified - as when the FBI presents a court order to Apple :-)

The AS in real life is also both a Controller and Processor. As a policy driven authority in Phase 2 it's just a processor. In Phase 1, when the resource authority (subject, custodian, whatever) is signed-in to the AS, the AS is a controller. This is where the "turtles all the way down" comes in. As soon as UMA technical or legal chooses to put the AS policies or actions under the control of someone _in addition to_ the resource authority, the resource authority can turn the AS into an RS and set up an agreement that points to an AS (the next turtle) that really is owned and controlled by the resource authority.

To map this to current events, Apple's iPhone 7 can introduce an UMA AS with a secure policy store that self-destructs if the credentials are mismanaged. That would meet my definition of an owned UMA AS and it's what I'm building as HIE of One. Is it the first turtle, or the last?

Adrian

_______________________________________________
WG-UMA mailing list
WG-...@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/

[John Wunderlich]

I may be seeing in the eighth colour, and if so, please call me out of scope, and we can move on.

On Feb 19, 2016, at 16:58, Adrian Gropper <agro...@healthurl.com> wrote:

"It's turtles all the way down, madam."

I'm not saying Eve is the madam. What I am saying is that the ISO concepts of Subject, Controller, and Processor are of limited utility to UMA technical or legal.

I fled to the ISO terms because ‘agent/agency’ are too protean and I am averse to directly linking to a particular country's legal framework - even my own (Blame Canada!). I think that they are useful constructs for the discussion. And I’m hopeful that they can be used as bridge terms between the UMA technical terms and various jurisdictions’ actual legal parlance. But as I’m relatively new to the group, and if the introduction/use of these terms is getting in the way of consensus/agreement I’m happy to set these terms aside. 

As long as in real life the RS has a _direct_ relationship with the Subject (and the subject's custodian in Eve's five bullets above - whoever they are, they have credentials that the RS recognizes) the RS is both a Controller and a Processor.

The “As long as in real life…” is a massive if statement that, were we to take the stories out of health care into another context but kept the same patterns, might not be so self evident - employee/employer, government/citizen, and so on. And Eve has already shared a working solution for one of those cases. 

 If we’re using the ISO definitions Controller and Processor are mutually exclusive roles. Here are the actual definitions from the standard. You will see that there are is only one subject, only one controller, and after that its processors all the way down - acting on instructions.

PII controller: privacy stakeholder (or privacy stakeholders) that determines the purposes and means for processing personally identifiable information (PII) other than natural persons who use data for personal purposes 

NOTE A PII controller sometimes instructs others (e.g., PII processors) to process PII on its behalf while the responsibility for the processing remains with the PII controller.

PII processor: privacy stakeholder that processes personally identifiable information (PII) on behalf of and in accordance with the instructions of a PII controller 

PII principal: natural person to whom the personally identifiable information (PII) relates 

NOTE Depending on the jurisdiction and the particular data protection and privacy legislation, the synonym “data subject” can also be used instead of the term “PII principal”.

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

[Andrew Hughes]

The conversation is confusing to me.

Is this a case where the Resource Owner (from the protocol doc meaning) grants authority to a different entity/actor?

How do other access control systems handle delegation of permissions?

How would UMA work if the Resource Owner is not a singular entity but rather a collection of entities?

If the protocol cannot express or recognize group actions or permission delegation the talking about legal agreements is premature.
Andrew.

Andrew Hughes CISM CISSP 
Independent Consultant
In Turn Information Management Consulting

o  +1 650.209.7542
m +1 250.888.9474
1249 Palmer Road,
Victoria, BC V8P 2H8
AndrewHu...@gmail.com 
ca.linkedin.com/pub/andrew-hughes/a/58/682/
Identity Management | IT Governance | Information Security 

[t...@bridgeidentity.com]

I told u that u could use bridgeidentity.com identities a  long time ago as neutral user centric portals.  Maybe a bit sooner than one could understand the importance.

[Adrian Gropper]

@Tim, I agree with most of what you propose but am hoping to tackle a much, much, smaller problem than capital-I Identity: 

The problem of how one individual or their custodians can own and control a set of private policies for issuing access tokens to standard APIs. 

This may be all that I'm hoping to achieve. I see it as a human right. I hope it is compatible with UMA as standardized and as deployed by institutions. 

An individual's ability to control, in the sense of my ability to control some information in my iPhone and my laptop, does not encroach on anyone else's freedom or prevent anyone from keeping all of their private policies in Facebook or on the blockchain or in a bank.

I'm simply doing my best to see that UMA, as deployed in practice, is compatible with practical personal autonomy and agency.

Adrian 

[Adrian Gropper]

@Andrew, the confusion arises when we try to complicate the legal agreements of Phase 1 with those of Phase 2 and later. In Phase 1, by definition, the agreements, both technical and legal, cannot be complete because UMA, by design, is meant to bind the RS and AS at a time when the client and requesting party are just not in the picture at all and therefore cannot be paerty to the Phase 1 agreement.

I propose that UMA Binding Obligations (or model contracts or whatever) be strictly separated into Phase 1 vs. Phase 2 and later. Maybe the terminology and definitions carry over across the two kinds of agreements or maybe we should not even try to share them.

There are an uncountable number of kinds of Resource Servers and Clients with APIs out there across things, industries, domains, jurisdictions, and business interests. When it comes to data (identifiable or de-identified) about a natural person, the set of kinds of authorizing parties is much smaller. It includes:

• natural persons,
  
• custodians voluntarily associated with a natural person,
  
• custodians associated with the natural person by the state, and
  
• entities serving the interests of multiple natural persons.
  

My proposal for the Phase 1 Agreement is to bind the particular resource API exposing information about a particular natural person to one or more of the 4 kinds of authorizing parties above. Each party to the Phase 1 agreement would be listed by name.

I would avoid use the term Resource Owner completely. What is a "collection of entities" when a resource refers to data about only one natural person?

I agree that the protocol Phase 1 must recognize group actions and permission delegation. That's why I propose that the Phase 1 agreement must name the authorizing parties, including groups, if any. This still has nothing to do with Phase 2 or later agreements.

Adrian

[Andrew Hughes]

@Adrian

From your description, it sounds to me that you are seeking the Operator of the Resource Server to agree to accept and use an Authorization Server that the Subject (one or more of your list of 4 possible candidates) specifies. (I think)

As long as the Operator of the Resource Server is willing (and I suspect that for some cases they won't be willing) to externalize authorization policy decision point functions to a (probably) previously-unencountered Authorization Server, then isn't this "simply" a case of writing a contract that specifies terms of use etc.? 

Perhaps there is a Discovery Service function that the Resource Server uses to find the AS and get endpoint information from the AS. 

But the big thing, I think, is to satisfy the Resource Server Operator that it is 'safe' to externalize authorization policy decisions. I.e. that the AS is operated at an mutually-acceptable level to deliver reliable, trust-worthy assertions.

Am I getting closer or further away from the point?

andrew.

Andrew Hughes CISM CISSP 
Independent Consultant
In Turn Information Management Consulting

o  +1 650.209.7542
m +1 250.888.9474
1249 Palmer Road,
Victoria, BC V8P 2H8
AndrewHu...@gmail.com 
ca.linkedin.com/pub/andrew-hughes/a/58/682/
Identity Management | IT Governance | Information Security 

[Adrian Gropper]

On Saturday, February 20, 2016, Andrew Hughes <andrewhu...@gmail.com> wrote:

@Adrian

From your description, it sounds to me that you are seeking the Operator of the Resource Server to agree to accept and use an Authorization Server that the Subject (one or more of your list of 4 possible candidates) specifies. (I think)

Yes. 

As long as the Operator of the Resource Server is willing (and I suspect that for some cases they won't be willing) to externalize authorization policy decision point functions to a (probably) previously-unencountered Authorization Server, then isn't this "simply" a case of writing a contract that specifies terms of use etc.? 

Maybe. I'm not saying that the specified AS is the only source of input into what the RS does (the so-called Adrian clause in UMA). I'm just saying that it's one input into the resource registration (Phase 1) agreement.

Perhaps there is a Discovery Service function that the Resource Server uses to find the AS and get endpoint information from the AS. 

Yes. I assume it's WebFinger (that's what Justin taught me) but it could be anything else. 

But the big thing, I think, is to satisfy the Resource Server Operator that it is 'safe' to externalize authorization policy decisions. I.e. that the AS is operated at an mutually-acceptable level to deliver reliable, trust-worthy assertions.

No. All we need to do is to satisfy the RSO that the AS is under my control. It's up to UMA as a technical protocol, to ensure that my choice for an AS does not endanger any other resource hosted by that RS. 

Am I getting closer or further away from the point?

You are much closer, particularly now that you are focused on Phase 1 and nothing more.

Adrian 

[Andrew Hughes]

@Adrian
If the RSO is OK with only having proof the AS is under your control, then that should be in the legal contract.

I suspect most RSO's would want more assurances than that - but again that would go in the legal contract.

And in both cases, there would be impact on liability for damages.

UMA the technical protocol has nothing to say at all about 'endangering ' other resources . That's all up to how the RSO implemented their access control system.

[Adrian Gropper]

@Andrew - What you say is confusing to me. I'm simply saying that a natural person has a right to technology that they own and control completely in the form of an UMA AS. UMA as a protocol MUST respect that right.

The RSO can choose to respect that right or not. The RS can ignore the AS regardless of who controls it. That has nothing obviously to do with UMA as a technical protocol.

As for the "endangering other resources" point. I bring that up because in health care the patient has a right to access (That does not seem to be the case in general. I know of only one other example which is credit bureaus). When there's a right of access, the RSOs look for excuses to block their duty to grant access and, in healthcare, they try to use the excuse that patient-controlled access would endanger the security of other resources at the institution.

Adrian

[Andrew Hughes]

Noted.

I think we are talking past each other a bit.

Let's take as given that the rights of the natural person exist as stated - and then set it aside for this discussion. It is a distraction because nobody disagrees with the point. Let's also take as given that some healthcare institutions don't like loss of control over access policy or other technologies related to their information repositories.

Consider this scenario:

A Resource Server Operator has implemented a fully-compliant UMA-protected Resource Server. They have entered into a legal contract with some Operator of a fully-compliant UMA Authorization Server for the purpose of using the Authorization Server for access authorization purposes in the simplest Alice-permits-Bob UMA case.

A Person has information records stored at the Resource Server.

The Person contacts the Resource Server Operator and asks the Operator to use a Personal Authorization Server for the Person's information records and to discontinue use of the original Authorization Server for those records. The only way to access the Person's information records is to satisfy the UMA policies defined at the Personal Authorization Server.

What should be in the legal contract between the Person, the Resource Server Operator and the Personal Authorization Server Operator?

Is that what we are discussing? (I think this is what we are referring to as the "UMA Phase 1 Agreements", right?)

If yes, then:

- in the 'happy path' where everyone does what they committed to do, we can probably set out the model terms and conditions for that legal contract in a fairly straightforward way.

- if the Resource Server Operator is operationally negligent or has done a poor job of implementing UMA (resulting in unauthorized release of information), then that's pretty straight forward as well (presumably the 'damages' clause in the contract)

- If the Person sets bad policy and grants access to the wrong people, that's probably pretty easy to handle too.

- Now, what if there's a problem with the Personal Authorization Server or Personal Authorization Server Operator?

Remember that a Resource Server in UMA relies on the Authorization Server to correctly identify/authenticate the Requesting Party and/or their Client software. Also to evaluate authorization policy correctly and reliably, then to mint the correct token for passing back to the Resource Server via the Requesting Party Client.

This is a complete transfer of policy evaluation responsibility from the Resource Server to the Authorization Server. All the Resource Server 'knows' is that they might see a request come in with a token that permits access to information - they don't have any way to 'see' how that decision to mint the token was made. (UMA Experts: please correct me here)

So, if the Authorization Server incorrectly mints access tokens, then the Resource Server would have no way to detect this.

To me, it would seem that the Resource Server Operator would want assurances about, or legal protection from, the actions of the Authorization Server and Authorization Server Operator.

andrew.

[Adrian Gropper]

@Andrew - thanks for the rewrite! I completely agree with it. All of it.

Which leaves us with the last paragraph: "The Resource Server Operator would want assurances about, or legal protection from, the actions of the Authorization Server and Authorization Server Operator."

How much of this is UMA (technical or legal)?

- Technical assurances might come from independent (of the AS) investigation by the RSO of the Client and RqP. Does the RqP have credentials that the RSO also recognizes? Does the RS have a way of registering the Client separately from the AS? In real life, in many or most cases, the RS and RSO already have these processes in place (e.g.: Google Account Passwords and Developer Console) before UMA ever existed.  How much of this should be supported by UMA or should it all be considered out-of-band?

- Legal protection comes from clear regulatory guidance that limits the RSO's liability. For example, the Office for Civil Rights (HIPAA police) clearly states: http://bit.ly/HEARTfromHIPAA - read bottom of p5 and top of p6. UMA's Phase 1 model clauses could adopt wording that makes this very clear. In addition, I maintain that UMA must add the capability to provide notice to the AS and/or the RO in order to facilitate this kind of liability limitation. This is one key use-case for our #shoebox endpoint upgrade.

Adrian

[John Wunderlich]

Andrew;

Good restatement (echoing Adrian)  but how do you incorporate regulatory requirements on the Resource Server Operator where such may constrain - from outside - the ability of UMA to operate as stated. Contractual rights and obligations, as I understand it, are superseded by legal requirements. So there will be cases where the data flow that Alice wants to authorize for Bob is illegal. My question is whether that is in scope of UMA/this subgroup, or out of scope? 

Case: Alice authorizes Bob to access her personal information. Alice lives in Elbonia, which forbids any outbound cross border flows of the PII of its citizens. The RSO also lives in Elbonia and has put in place technical controls (like DLP software) to block all such flows. Does any of this belong in, or to, UMA?

This is a fork of your conversation, because it deals with the rights of the natural person you put aside. Like any right, this is not absolute, and whether or not we agree/disagree with the Elbonian policy it is the law of land and the Elbonian state has determined that the natural person’s rights for approving data flows terminate at their border. More nuanced cases involving genetic data, intellectual property etc could be found - all of which are restatements of “Alice is the legitimate owner of the resource, but does not have unfettered rights to determine to whom said data may flow."

[Adrian Gropper]

@John - IMHO this is not UMA.

This is what I tried to say with: "turtles all the way down". UMA is about technology - it's a protocol. As soon as we decide that Alice does not have a right to control the UMA AS part of the UMA protocol we're going down a  turtle-hole. Do the Elbonian police come and crack Alice's iPhone AS to read her policy on cross-border PII? Or, do the Elbonian police come to the RS and say "thou shalt install technical means to prevent cross-border PII"? The Ebonians might as well do both.

Adrian

[Eve Maler]

Thanks, Andrew, for picking this apart -- and I'm guessing that the Authorization Server Operator may even be the Person themselves, depending on how they acquired/deployed the Authorization Server. Did they stand up some open-source software on a server they run? Did they write the software? Or maybe they are always the ASO if the relationship is 1:1? Not sure.

On a technical level, deciding what services are UMA-conformant could help. (A test suite is already on the docket of our companion UMA Dev group.) It's possible to pull technical considerations into our model clauses, such as conformance requirements, security best practices, and so on.

On the other levels, crafting boilerplate for common use and enabling drafters of agreements to point to relevant regulations could help -- which is why we're here. Again, I'll point to all of the clauses that have already been drafted having to do with the relationships among the Authorizing Party, the Resource Server Operator, and the Authorization Server Operator for phase 1 use. The only reason we haven't quite yet dug into and revised these is because we're slightly hung up on the definition of an Authorizing Party: We first have to gain consensus on the { "resource owner" vs. "some guardian or appointed person acting on behalf of them" } as a prerequisite.

(Again, I find the question "How much of this is UMA?" to be, well, weird. Looking at our charter for the last 5-6 years, the answer is clearly yes. Can we stop asking, and just solve the problems on our agenda?)

Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

[Mark Lizar]

Very nice point and well articulated in my opinion. 

I think this  also relates back to the issue of terminology and the use of terminology.  The MVCR is based explicitly on legal language.  We use the normative terms found in ISO as these have been determined after a decade of analysis of terminology. 

The PII Principal is equivalent to the Data Subject, but it is in no way perfect and it maps to UMA akin to a Role that is sometimes called the Resource Owner.  Which in my point of view doesn’t mean the RO can’t have two roles at one time -RO and Data Controller. 

It is just that this terminology maps to legalese, which the MVCR uses to address what is considered consent. 

- Mark 

<signature.asc>_______________________________________________

[Adrian Gropper]

UMA is not about consent. It's about authorization. As far as I'm concerned, at least from the healthcare perspective, consent is the excuse for not seeking authorization. Consent is what is used by RSOs when they don't want to seek authorization. Even worse, consent is used to even avoid notice of how data was used after the fact. At best, consent just confuses UMA and legalese is unlikely to solve that confusion.

Adrian

[Mark Lizar]

Adrian,  

I agree, in that authorisations and permissions (AKA access control) is what happens once their is consent, consent is essential a legal (or authoritative) policy .   Authorisations it seems would essentially be permissions that are defined into authorisations in UMA speak.   

@Adrian, do you think authorisations, from a policy perspective, would appear to be a subset of permissions which is a subset of consent?   i.e. authorisations are down stream of the consent?   

- Mark

[Adrian Gropper]

Authorization is what happens in UMA Phase 2. I would not describe UMA Phase 1 as consent. It is primarily delegation. In Phase 1, the person who would, in the absence of UMA, be asked to sign a consent agreement is offered the opportunity to sign a delegation agreement instead.

So yes, both the consent and the delegation agreements are upstream of authorization but they are mostly different technical and legal structures. Today, we are typically asked for consent because we do not have a standards-based authorization server. We don't have UMA.

As UMA comes on the scene, people will be able to replace consent with delegation to a policy-based authorization server. If the authorization server is "off-line" or otherwise at odds with a particular Phase 2 transaction, then the Phase 1 agreement does not operate.

Can we confuse this simplistic picture by combining elements of consent and delegation into the UMA Phase 1 agreement? Of course we can. But I don't see how that helps anyone. As UMA, we need to design the best possible protocol for managing delegation to a separate policy-based authorization server. Adding the concept of consent seems like a distraction to me.

Adrian

[Debbie Bucci]

I have been following the relate threads and I am totally confused about the threads but want to comment on consent and authorization.
  
I searched the web for various dictionary  entries for consent; authorization (n)/ authorize (v) are terms often are used as synonyms.   I then queried health IT website for guidance  and found.... http://www.hhs.gov/hipaa/for-professionals/faq/264/what-is-the-difference-between-consent-and-authorization/index.html

Separating consent from authorization makes no sense to me - seems impossible.  Consent is an form of authorization.  According to the reference above - often *simple consent* is not enough.     I surmise  that 3rd party [consent] and/or delegation is an authorization according to the definition above.  Furthermore  - even if not a HIPPA covered entity (Heath IT domain) the RO gathering accounting information re: disclosure seems like an important legal construct to have. There are 3rd party open source efforts (consent2share primarily focused on CFR 42 part 2) that may already have 80% of the legalese worked out that the UMA legal group may want to reference - if they have not already done so.   I know Kathleen and others that participate in the HL7 and other security groups could advise in this area.

There are stand alone separate policy based authorization systems in place today (dare I include xacml?)    Authorization Server is not an UMA construct is it?  Discussions of a separate AS is even more distracting.  Do not understand the concerns.

[Debbie Bucci]

Think I meant to say Resource operator gathering/retaining... really bad on the terminology.   Meant to send to the list but guess it did not get there.   Will leave up to others to decide if appropriate.

[Adrian Gropper]

Mark Lizar found a HIPAA description of the difference between consent and authorization. https://clearwatercompliance.com/hipaa-hitech-news/difference-consent-authorization-privacy-rule/

Notice that consent is like a contract of adhesion where if you don't consent, I don't have to treat you. Consent, once granted, (and obviously it's granted, otherwise you don't have a relationship with the provider at all) leaves the decision of who to share data with up to the Resource Server (the provider).

Authorization, on the other hand, is like UMA Phase 2. The provider has to serve you whether you authorize a particular transaction with a specified third-party or not. This is pure UMA Phase 2.

Adrian

[Mark Lizar]

Adrian - Please don’t confuse the MVCR and our approach to notice and consent with contracts of adhesion. 

[Debbie Bucci]

OCR is authoritative in my book especially when it comes to health IT.  I think their explanation is simple and elegantly laid out.  Easy to understand.  Hints at the flip side - accounting of disclosure.

The consent you seem to worry about most- delegation 3rd part access is an authorization made by a patient that a resource operator must honor.

[smarthart]

+1  Debbie, 

& thanks for the link to Consent2Share, more information here —> http://wiki.siframework.org/SAMHSA+Consent2Share+Project