-
Notifications
You must be signed in to change notification settings - Fork 21
UMA Legal: Background and Context
Here is a selection from the minutes of the July 16 meeting as they relate to formation of the UMA Legal group:
The license model we discussed last time could be extended with the machine-readable license language. Tim brought up if we bake the language into the scope (or even resource set?) descriptions; this is an idea Dazza had a long time ago.
Eve calls this a "notice model" because the act of using the scopes (exercising the license?) binds the RqP. Jon would say, rather that the RO is the licensor and has issued the license; it's the opposite of a notice model. You can have choice exercised through the issuance of multiple different licenses.
Eve's attempt at a dialogue that achieves Bob's consent need not be mapped to contract; licensure could work as a model too, says Jon.
The time seems to be right to start having legal subgroup meetings to come to recommendations about RO-RqP, RS-AS, and any other transactional relationships in the UMA environment.
Adrian suggests inviting Jim Hazard as well. The goals might be:
· Jurisdictional friendliness internationally · Applicability to many different vertical and horizontal use cases, including health · Support of higher-level access federation trust frameworks and similar efforts
[Comments: A firmer grounding in contract enforceability and other sources of legally binding rules would be helpful. The scope authorization information seen by a user when they grant consent to access a protected resource is important. The notes above suggest this information has been discussed as an opportunity to provide notice or grant a license. These are both valuable and accurate views. It is also true that the moment a user sees terms of authorization and has the choice whether to grant consent is an opportunity to create and preserve evidence of a binding agreement between the parties (current and future) to transactions conducted based on the consent then given. It is recommended that the terms of authorization be construed as material parts of the agreement between parties to the transactions involving the authorizations provided by the user.]
Attending: Eve, Scott, Adrian, Dazza, Jon, Mark, Jim, Thomas, Tim
Our schedule and deadline are meant to be a forcing function to align with UMA V1.0’s and V1.0.1’s needs.
Eve read the draft mission statement in italic:
Develop recommendations about resource owner-and-requesting party [Alice-and-Bob], resource server-and-authorization server [service-and-hub], and any other transactional relationships in the UMA environment, keeping in mind international jurisdictional friendliness; applicability to many different vertical and horizontal use cases, including health; and support of higher-level access federation trust frameworks and similar efforts.
What does “transactional” mean here? It’s probably not a term of art, just a word. Scott could see substituting “interaction”, but it’s not strictly necessary. Transactions imply some formalism. When you have intermediation without being able to monitor the transaction fully, you have a problem. He has seen problems in supply chains where there are no measurements the middle. Reliability is a goal. The parties and intermediations need to be listed and understood.
Eve described the overall goal of the exercise, from her perspective, is giving comfort to those interested in deploying UMA — in any size of “cloud” — that any sets of parties involved who have misaligned interests can nonetheless have enforceable and predictable ways to do it. Adrian’s take is a little different, but related: For those parties in a potential ecosystem who are not interested, he wants to create some kind of “safe harbor” that shifts liability appropriately away so that they will be willing to play along. He thinks these will be the resource servers in healthcare. Scott says this is two ways of expressing the same thing. Liability is just cost. Standardization of result, such as standard contracts, is one of the ways, to reduce such costs.
Accelerate adoption!
Reduce inhibitors!
Dazza notes that the UETA, with the essential notion of actors and actions, is relevant. At the end of the day, you may have hundreds of intermediaries. A good place to start is the use cases, such as those Adrian sent. The selection of use cases inherently surfaces the parties of interest to us, and sets the prevailing context. Enumerating the transactional relationships is something we’ll have to do.
What would deliverables look like to meet these goals, in order to be most effective? It may be too early for this.
What makes a good use case? Generic UMA use cases count, as well as “things going wrong” use cases. These are like the “negative tests” in software testing. And we need success and failure conditions. In fact, all of the warnings you see on consumer goods are the result of something having gone wrong. (“Do not use this toaster while sleeping.” Samples: http://idiot-dog.com/disclaimer.html :-)
Mark notes that the MVCR (Consent Receipt) work is getting to V0.7. There are some strong relationships here. Consent receipts are a species of transaction receipt, and since UMA is bristling with transactions, there are a lot of opportunities for receipts. If you add consent (a consent record) to a transaction, you can bind them. Adrian connects this to his use case that mentions “accounting for disclosures”, which Alice would want to hang onto for dear life, since it’s the only evidence that her data was shared — similarly to a confirmation number received when travel plans are changed. The correspondence to the logs of the servers where their own liability gets protected is a key element.
Mark remarks that different UMA scenarios along the lines of “who owns the data” (at the resource server) may be an important dividing line. Adrian dislikes “data ownership”, other than RTBF. Scott thinks “data ownership” is a nonstarter, but “data rights ownership” could be workable.
Next steps:
- Anoint Dazza our GitHub wiki master — thank you, Dazza!
- Begin use case collection and label them on wiki with “legal-*” labels for emergent categorization . AI: Eve, Adrian, and Mark especially: Contribute starter use cases . AI: Dazza: Explain in email how we engage on the wiki
- Agenda for next time: . Remedial UMA flow explanation . Use case discussion and logging/receipts and data rights ownership . Licensure vs. contract
COMMENT: Section 8.4 and 9 describe direct legal benchmarks. Sections 3.2 and 10.x relate to key transactions and log data forming evidence relevant to expected legal conduct and results. Logging is a key way to create and preserve relevant evidence and a good example in rules that apply to parties using OpenID Connect can be found here: https://github.com/mitreid-connect/trust-framework/blob/master/TrustFramework.md#36-event-logging A great example is with Consent Receipt work. This is fundamentally about evidence in the context of this topic: https://github.com/xmlgrrl/UMA-Specifications/wiki/UMA-Legal:-Use-Cases,-Roles-and-Obligations#32-tieing-evidence-to-obligations
Parties operating and using UMA software entities have opportunities to establish agreements about mutual rights, responsibilities, and common interpretations of UMA constructs for consistent and expected software behavior. These agreements can be used to improve the parties' respective security postures, and written profiles are a key mechanism for conveying and enforcing these agreements. Section 6 discusses profiling. Section 5 discusses profiling for extensibility. [UMA-obligations] discusses the development of binding obligations.
The authorization server comes to be in possession of resource set information that may reveal information about the resource owner, which the authorization server's trust relationship with the resource server is assumed to accommodate. However, the client is a less-trusted party -- in fact, entirely untrustworthy until authorization data is associated with its RPT. The more information about a resource set that is registered, the more risk of privacy compromise there is through a less-trusted authorization server.
The primary privacy duty of UMA's design is to the resource owner. However, privacy considerations affect the requesting party as well. This can be seen in the issuance of an AAT, which represents the approval of a requesting party for a client to engage with an authorization server to perform tasks needed for obtaining authorization, possibly including pushing claim tokens.
Parties operating and using UMA software entities have opportunities to establish agreements about mutual rights, responsibilities, and common interpretations of UMA constructs for consistent and expected software behavior. These agreements can be used to improve the parties' respective privacy postures. For information about the additional technical, operational, and legal elements of trust establishment, see [UMA-obligations]. Additional considerations related to Privacy by Design concepts are discussed in [UMA-PbD].
The resource server uses the protection API's permission registration endpoint to register a requested permission with the authorization server that would suffice for the client's access attempt. The authorization server returns a permission ticket for the resource server to give to the client in its response. The PAT provided in the API request implicitly identifies the resource owner ("subject") to which the permission applies...
This specification registers the claim defined in Section 3.3.2.
Claim name: permissions Claim description: Array of objects, each describing a set of scoped, time-limitable entitlements to a resource set Change controller: Kantara Initiative User-Managed Access Work Group - wg-uma@kantarainitiative.org Specification document: Section 3.3.2 in this document
This specification registers the well-known URI defined in Section 1.4.
URI suffix: uma-configuration Change controller: Kantara Initiative User-Managed Access Work Group - wg-uma@kantarainitiative.org Specification document: Section 1.4 in this document