-
Notifications
You must be signed in to change notification settings - Fork 21
UMA Legal: Use Cases, Roles and Obligations
COMMENT: From Adrian
There may be only 4 distinct use-cases for UMA in healthcare. I wrote this in order to prepare for the legal subgroup this morning. Feel free to share if it's useful.
- The multiple portals problem - Alice wants to direct sharing herself Alice wants to manage her EHR-1 and EHR-2 authorizations in one place. We call that place the AS. Alice registers her AS with her practice’s EHR-1. Alice registers her AS with another practice EHR-2. From then on, Alice can sign-in to her EHR, view accounting for disclosures, and manage authorizations.
- Delegation to a custodian Custodian creates an AS for Alice. Custodian has a sign-in to Alice’s AS. Alice registers her AS with her PCP’s EHR-1. Alice registers her AS with another practice’s EHR-2. From then on, Custodian can sign-in to Alice’s EHR, view accounting for disclosures, and manage authorizations.
- Alice wants to authorize her PCP for directed sharing Alice registers her AS with her PCP’s EHR-1. The PCP shares an Alice-specific context with Bob. Bob’s client EHR-2 presents claims to Alice’s AS, gets authorization. EHR-2 accesses resource from EHR-1.
- Alice wants to be discoverable Alice registers her AS with her practice’s EHR-1. Alice picks up a flier for the state HIE with a Q/R code, reads their Privacy Policy Alice signs-in into her AS and scans the Q/R code. The HIE allows Alice to pick her discovery attributes, registers Alice’s AS. Bob’s client signs into the HIE, discovers Alice, gets authorization to EHR-1.
COMMENT: from Binding Obligations
2.1.1 Requesting Party-Authorizing Party: Adhere-to-Terms
2.1.2. Requesting Party-Authorizing Party:
Make-Factual-Representations
2.1.3. Requesting Party-Authorization Server Operator:
Supply-Truthful-Claims
2.1.4. Requesting Party-Resource Server Operator:
Is-Legitimate-Bearer
2.2.1. Resource Server Operator-Authorizing Party:
Delegate-Protection
2.2.2. Resource Server Operator-Authorization Server
Operator: Register-Accurately-and-Timely
2.2.3. Resource Server Operator-Authorization Server
Operator: Respect-Permissions
2.2.4. Resource Server Operator-Requesting Party:
Give-Accurate-Access
2.3.1. Authorization Server Operator-Authorizing Party:
Follow-Policies-Accurately-and-Timely
2.3.2. Authorization Server Operator-Resource Server
Operator: Follow-Policies-Accurately-and-Timely
2.3.3. Authorization Server Operator-Requesting Party:
Request-Limited-Claims
2.4.1. Authorizing Party-Requesting Party: Adhere-to-Terms
2.4.2. Authorizing Party-Authorization Server Operator:
Introduce-Resource-Server
2.4.3. Authorizing Party-Resource Server Operator:
Introduce-Authorization-Server
What are the definite and common touchpoints between parties conducting UMA transactions? These are good places to look for purposes of understanding how and when any given party adopts an UMA role. These are also good places to reveal how and when any given party that has adopted an UMA role will then form UMA relationships with other parties in who have also adopted their own respective UMA roles.
The following are examples of currently active named roles. A key task is ascribing each applicable role to each "actor" in each UMA use case. To the extent additional active contexts emerge, such as use of a license, there will likely be additional named roles corresponding to that aspect of the context within which each UMA actor exists and operates. The most useful aspect of naming roles is it provides a basis for revealing or establishing the functions and obligations allocated to each role and also for identifying the relationships between each role. This is, in a sense, the work of a legal group. It is also the work of business and technical groups because the roles arise from each of those three fields.
UMA Roles
(extracted from Binding Obligations)
- Requesting Party
- Resource Server Operator
- Authorization Server Operator
- Authorizing Party
Statutory Privacy Roles
(extracted from ISO 29100)
- 2.11 PII controller
entity (or entities) that determines the purposes and means for processing PII other than individual 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.
- 2.12 PII principal
natural person to whom the PII relates NOTE Depending on the jurisdiction and the particular data protection and privacy legislation, the concept of a “PII principal” may also be defined as a “data subject”.
- 2.13 PII processor
entity that processes PII on behalf of and in accordance with the instructions of a PII controller
- 2.26 third party
an entity other than the PII principal, the PII controller and the PII processor, and the persons who are authorized to process the data under the direct authority of the PII controller or the PII processor
UMA Healthcare Use Case Roles
(Extracted from Adrian's use cases)
- Alice
- Bob
- EHR-1 Operator
- EHR-2 Operator
- PCP (Primary Care Provider)
- Custodian
An efficient and effective moment to adhere role-based obligations in a commercial transaction or other legal interaction is at the time a party initially adopts their role in that system. This is like changing state from the role of "window-shopper" to "paying-customer". In the online world, the role of paying customer and merchant also has set of contracts associated with it. Ideally, no user will conduct transactions until after they have clearly assented to the agreements related to the role(s) associated with their account relationship(s). A person adopts the role of "student" of a university when they have, among other things, agreed to a set of terms that define their role and corresponding rights, obligations and certain key relationships. Similarly, a person takes on the role of "account holder" with a depository bank when they, among other things, sign the contract to set up a bank account. A person has many roles that have no clear legal agreements associated with them in many situations including social, family, workplace, political and other contexts. A person may even develop a more formal role such as "client" with a lawyer based only on the context of conversations but without any written agreement. Some of these roles have definite legal consequences based on other bodies of law like statutes, regulations and judicial holdings. In some cases, roles may have multiple relevant contracts that are related to the role but none directly focused on the role, such as when two or more people discuss a business transaction at a professional conference. Such people may be playing a clear social role of "prospective buyer" and "prospective seller" but they have no direct relationship or agreement with the other party.
There may be other relevant contracts in this situation, such as an NDA and other terms with their respective employers, agreements with professional associations they belong to, codes of conduct by organizations that have provided one of the parties with an accreditation or certification, etc. In the absence of a clear and definite contract it can be difficult to reliably assess the rights, obligations and other expectations with respect to the parties playing the other roles.
With UMA, there are valuable opportunities to ensure parties are aware of and have agreed to minimum expectations associated with the roles and relationships with other parties conducting UMA enables transactions. In part this is because UMA enabled transactions occur online and not in physical spaces. Therefore, in general, the moment a party adopts an UMA role and the moment an interaction is conducted with any party in another UMA role can be anticipated and to some extent designed to structure clear and reliable legal relationships. In addition, because UMA uses OAuth 2, there are a very well suited set of key legal "touchpoints" that each party will have experienced in order to take an action in their UMA role or to conduct an interaction with any other party playing an UMA role.
Some of the key "gate" events associated with roles include:
- "Client Registration" (manual or dynamic) when an app or service is on-boarded
- "Authorizing Party" activates an account with an AS
- "Authorizing Party" grants permissions to a Requesting Party
What are the key events and threshold conditions that necessarily must happen for any given party to a) adopt an UMA role and b) to interact with any other party in their respective UMA role and c) to conduct a transaction effectuating or relying upon consent to authorize access to protected resources? These are very good nexus points to identify the candidate events best suited for ensuring agreed obligations adhere to the UMA roles and relationships of legal parties.
Linking Actors, Actions and Obligations
In meeting notes of past UMA calls it appears that licenses and notices have been discussed as legal instruments for linking obligations to parties playing UMA-roles.
Licenses
The grant of a license is one way to form a contract and contracts are one way to ensure parties enforceably agree to the same sets of rights and obligations with respect to activities (including transactions) and property (including personal data and other digital assets). Licenses are, however, a somewhat specialized legal instrument and cover a relatively narrow set of circumstances.
The moment a party agrees to a license is a key legal event. This event is known as "contract formation". The agreement to terms certainly may in some cases specifically relate to license use of intellectual property belonging to the resource owner. But the underlying transactions and grants of authorization can cover many common OAuth 2 use cases that do not involve the license of any property right of the resource owner. Other common examples beyond the license paradigm involve the contractual mutual commitment of parties to provide or receive a wide variety of services, to conduct a range of transactions or to take many other types of actions.
Notices
From a legal perspective, the agreement to terms also provides evidence of notice provided to a user. The use of notices in a legal context is important but also covers only a relatively narrow set of situations. Consider this example: when you walk into a store to buy mobile phone service does the provider simply show you the contract so you have been put on notice of it, or do they ask you to sign it and give you a copy for your records?
It is possible to structure a "notice" so as to ensure a person has provided acknowledgement that they received the notice, such as by checking a box or signing a paper record. Having evidence that a party has provided some affirmative acknowledgement of notices is an important foundation for holding that party to the content of the notice. Otherwise, one merely has afforded "constructive notice" and not "actual notice" and therefore has created a much weaker basis for later holding the party put on notice to the terms of the notice. In any event, if notices were to be used as a legal instrument for creating UMA legal obligations then it would be useful to structure deployment of UMA such that each party acknowledged the notice and the best time for this is the moment when each party takes the actions necessary to adopt their UMA role(s). This raises the question: if for UMA a person is going to be put on notice of terms, would this be a good candidate context to consider using basic contract law?
The act of creating and preserving evidence of user assent to terms provides a clear record to all parties concerned upon which future actions can prudently be based. This act is commonly known as an “electronic signature” and it assumes the parties (the user and the other parties) are agreeing to binding obligations. The context and circumstances surrounding this use case should demonstrate that an ordinary reasonable person would have understood what was happening.
Some services use the flashing of OAuth 2 permissions as though it is nothing more than putting the user on notice and could plausibly be accomplished as a tiny link on the bottom of a screen of text (as happens with many terms and conditions, privacy policies and other user agreements today). The legal concept behind this view is that people who have been put on notice of terms and had an opportunity to review them have adequately agreed. However, this concept is fundamentally unfair to individuals who are presented with such terms as a "take it or leave it" condition of using a service and more to the point it is well documented that people do not in fact review or understand or agree to such terms. These factors put the method of "notice" in a low priority position with respect to individual resource owners. Conversely, an individual resource owner should have lower expectations that obligations will adhere to third parties if the only point of legal contact with the obligations was notice with no acknowledgement. This approach, as applied to other parties (eg commercial businesses in their UMA role as "resource requestors" or "Resource Server" providers) leaves a lot of room for those parties to later argue that the obligations do not apply.
By contrast, however, the cornerstone of OAuth 2 is an explicit user action that clearly indicates a human has assented to a specific set of authorizations. All of the authorizations are visible to them on the same screen assent is provided. This could not be a more obvious legal interaction pattern. It is called “contractual assent”. Assent is the basic mechanism used for UMA types of grants, which depending on the context could also be known as “consent” or “approval” or “authorization” and most notably the execution an “electronic signature”.
Similarly, the moment a party affirmatively clicks to consent to a developer agreement (if they are registering an app or service as a "client" for example) or takes the other actions necessary to provision UMA roles in a system provides a legal nexus point to ensure contractually enforceable terms are applied. To understand what terms would or should apply, it is currently good practice to look to the constellations of providers of OAuth 2 and other claims based federations and looser networks of transacting parties. There are common clauses, compatible roles and other existing customs in use that can provide the starting point for building compatible UMA-focused contractual agreements.
One key legal aspect of UMA is that it enables authorization for future automated transactions. This can be a major convenience and it is also strategic for enabling an architecture that can put individual people in the center of personal data control because it decouples the account relationships between the authorization service and the resource service. This also has legal implications because it means a person is providing consent for specific transactions and legal parties that are not yet known. Typically, the moment a person provides an OAuth 2 consent it is in the specific context of affording access permissions to named parties (eg "Dropbox, inc" or "MIT" etc) using named applications or services (the "clients" that are registered and have authorization tokens already hence are in a position to be granted access by a given user). With UMA, the defined policies and scope-based protected resource access authorizations must sometimes be applied to as yet unknown future parties and apps/services.
The risk based decisions are therefore more complex and the potential types of business relationships can not be assessed. The future business (not technical) roles and relationships corresponding to UMA access could involve a wide array of different legal scenarios, including employee/workplace, consumer/commercial, patient/health, citizen/political, social/friends, parent/family, broker/investor, student/school, etc. The future business/legal roles and relationships associated with use of UMA roles could therefore correspond to different sets of important rights, obligations that could change or even reverse expectations about data ownership rights and other key deal points upon which authorization decisions would be premised.
Managing Legal Obligations for Future Transactions
When the user sees the individual authorizations connected to a scope and chooses to grant consent we have a major legal nexus point. This is a central nexus point of time, place and manner for parties to agree on the same thing. This is the moment of value and of opportunity to structure the deals, relationships, transactions and other expectations of the parties to that agreement.
UMA Legal Consent to Future Automated Transactions Through Electronic Agents
UETA: “A contract may be formed by the interaction of electronic agents of the parties, even if no individual was aware of or reviewed the electronic agents’ actions or the resulting terms and agreements.”
“A contract may be formed by the interaction of an electronic agent and an individual, acting on the individual’s own behalf or for another person, including by an interaction in which the individual performs actions that the individual is free to refuse to perform and which the individual knows or has reason to know will cause the electronic agent to complete the transaction or performance.”
“Automated transaction” means a transaction conducted or performed, in whole or in part, by electronic means or electronic records, in which the acts or records of one or both parties are not reviewed by an individual in the ordinary course in forming a contract, performing under an existing contract, or fulfilling an obligation required by the transaction.
“Electronic agent” means a computer program or an electronic or other automated means used independently to initiate an action or respond to electronic records or performances in whole or in part, without review or action by an individual.
“Electronic signature” means an electronic sound, symbol, or process attached to or logically associated with a record and executed or adopted by a person with the intent to sign the record.
Applying Terms and Constructs to UMA
Deploy UMA systems such that an electronic signature clearly authorizes an electronic agent to conduct pre-defined future electronic transactions on behalf of and binding upon that user.
Breaking that down, at deployment time, one would look toward the following sorts of things:
- The electronic signature is now commonly accomplished by OAuth 2 via manual user action of clicking a “yes” option (the proverbial big green button). For UMA purposes, it would be wise to clearly signal a legal signature experience at the moment when a consent is given authorizing future UMA type electronic transactions.
The electronic signature can in theory be effectuated by the current practice of simply manually clicking a green button. However, this practice can be shown not to constitute a valid legal signature because most people do not believe they are performing an action “with the intent to sign” a contract or other agreement when they click those buttons. As the process of clicking to the next screen gets more and more routine it less and less resembles the important social, business and legal decision to sign on the dotted line. Therefore, some additional gating ceremony is needed at the juncture of providing consent in order to establish a clear record of a deliberate affirmative action by the user warranting the legal conclusion that the user intended to provide their signature authorizing later automated transactions on their behalf and to which they presently agree to be legally bound in the future.
The authorization is exists and can be captured at three levels: human readable, machine readable and lawyer readable dimensions of what the user authorizes. Evidence demonstrating the authorizations granted by a user should be created and preserved for each consent provided and that evidence should be equally accessible to all parties to the transactions authorized by the consent. The human and technical authorizations can exist as a small JSON object (existing practices suffice) and should include a link or links to the relevant contracts or other instruments intended to legally define the transaction.
The human readable authorization is what the user sees when they click the green button and it is what should be primarily responsible for defining the expected business and legal outcomes resulting from that user action. The machine readable authorization is technically defined primarily by the respective scopes correlating to the permissions displayed to the user defining what they are consenting to approve. The lawyer readable authorization is defined by the contracts, licenses, statutes, regulations, judicial holdings and other legal rules applicable to the relevant transactions and the parties. an electronic agent (user agents and other services via OAuth 2 enabled system).
From a legal perspective, the most important aspect of records like logs and receipts is "evidence". The work on Consent Receipt is a direct example of how logging and record keeping can provide reliable evidence of the transactions and other actions of parties using UMA. Creating and preserving the right evidence of transactions is important for basic service delivery (for day to day operations and performance measurement as well as continuity in the event of disruptions and other direct business purposes) and also the legal purpose of ensuring compliance with rules and capability of proving what happened in the event of later disputes and other reviews.
For most legal purposes, a transactional log file would suffice. As a starting point for thinking of minimum legal requirements to effectuate UMA-compliant logs, the following is offered:
The log should contain entries for each consent. A copy of the relevant info of each entry should be readily accessible to or sent as acknowledgement or receipt to each party to whom it is relevant. The fully entry for a consent should indicate the relevant parties, the authorization granted by the consent, links to relevant legal rules and minimum system metadata (date-time stamp, app IDs, device ID’s, etc). Objective test: From the log file, a neutral third party should be able to identify the relevant parties, the authorizations to which consent was granted and establish basic environmental transactional metadata (ie: how/when/where the actions took place). Periodically posting the digest of a hash or encrypted hash of consent transaction logs to the legal notices section of a newspaper of wide circulation and/or to a generally accepted blockchain of wide distribution would be a good practice.