...

You can find a description of the overall UMA User-Managed Access proposition here: http://tinyurl.com/umafaq.

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 our ad hoc "legal subgroup".

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.)

Mission

The animating mission of the legal subgroup guiding us in 2015:

...

Sources of liability tension

...

These are some key pairwise trust 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.

...

Here are some of our use cases?

• When Alice sets up criteria for access to a digital data resource of hers, such as "Only Bob can access this", can she ensure that the other actors in the authorization chain are doing their best to make sure Bob "is who he says he is" by the time he (someone) actually gets access?
• If Alice wants to impose limitations on how Bob uses her stuff using business-legal methods vs. some kind of (say) encryption or DRM methods, such as "Bob must promise not to share this data with third parties", how can she ensure these limitations stand up?
• Can the host of some sensitive information of Alice's, such as personal data, trust an authorization service that promises to do the job of protecting that information in an outsourced fashion? 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 an authorization 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).Can an authorization service rely on the hosts of Alice's data and the client applications that Bob uses to operate correctly in their UMA roles?
• Can the host of Alice's data ensure that it can keep out of legal trouble even if Alice's authorization service appears to want it to share data with a recipient who is in a jurisdiction to which personal data is not allowed to be sent?

Model text

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

"...an 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 draft model text. Only the "alpha" draft model textdefinitions have been worked on as of 1 April 2016. It helps to know how to navigate CommonAccord text: First, click on 0.md to get the current full text, and the "Document" link to expand the Source view into a proper document.

Additional artifacts

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