-
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
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 the time, place and manner when parties agree to 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.
The grant of a license is a very narrow example of the broader legal opportunity canvas I just described. The agreement to terms certainly may in some cases be specifically to license use of intellectual property belonging to the resource owner - can cover many common OAuth 2 use cases that do not involve the license of any property right of the resource owner but do 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. From a legal perspective, the agreement to terms also provides evidence of notice provided to a user. But 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? 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 terms and conditions, privacy policies and other user agreements today). 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”.
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.
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.