Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

UMA Legal

Part of the UMA WG's work is overtly technical, and part of the work explores other layers of the BLT (business-legal-technical) sandwich. The documents here reflect work in these other areas, many produced by the ad hoc "legal subgroup" (subgroup notes are here). The overall goal of the subgroup: Accelerate adoption and reduce inhibitors in a business context.

(A few additional artifacts are available on the WG's GitHub wiki.)


The animating mission of the legal subgroup in 2015:

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.

The sharpened mission in 2016:

Focus on:

  • Drafting model text (the term and abbreviation definitions and the model clauses)
  • Gathering requirements for the environment for using the model text 
  • Being guinea pigs for the environment

Target Q1 for external beta review of the model text. "Accordion" the environment requirements to account for budgetary uncertainty.

Sources of Liability Tension

These are some key pairwise relationships we are exploring for the "liability tensions" within them, that is, the misalignment of incentives that leads to a reluctance to deal with each other, mistrust, or added friction in decisions to use or deploy UMA.

  • RO-RqP: Can Alice trust Bob with access to her stuff? If she wants to impose "purpose of use limitations" using business-legal vs. (extra-UMA) technical methods, will they stand up?
  • RS-AS: Can the host of sensitive information trust a service that promises to do the job of protecting that information? This is roughly akin to the challenges of federated authentication, only for authorization. A difference is that in circumstances in which the RO chooses their own AS, there are elements of this arrangement the RS can't protest about (but still some elements they can).
  • RO-AS: Can Alice trust a service to do as she bids when it comes to protecting her stuff, if she didn't personally hand-code it? (Can consent receipts help?)
  • AS-OAuth client apps: Last and potentially least in importance for now: Can the authorization server rely on the OAuth clients sufficiently to provision them with credentials? This includes both UMA RS's and UMA clients (see this diagram for an explication of how this works).

Model Text

The model text work is being encoded in the system. CommonAccord is:

" initiative to create global codes of legal transacting by codifying and automating legal documents, including contracts, permits, organizational documents, and consents. We anticipate that there will be codes for each jurisdiction, in each language. For international dealings and coordination, there will be at least one "global" code."

Here is the "alpha" draft model text.

  • No labels