"Legal structure" is a good thing to work for, and could be taken to mean something a bit different.  It could mean the set of documents that are needed and the set of issues that need to be addressed.  This how lawyers usually work and there are lots of artifacts of this method easily available, so we fit with a large body of practice.

The actual documents, their names and the workflows vary a lot, but the issues repeat and the current processes are inefficient and opaque. A little progress somewhere might propagate across a lot of uses.  In health, Adrian and I did a few laps in the NYP swimlanes and with Primavera I did the model patient consent for the Global Alliance for Genomics and Health.

Privacy policies might be a good entry point.  The advantage is that they are ubiquitous and customer-facing and usually not private, proprietary, or otherwise a point of jealousy.  Their disadvantage, that they are completely lopsided, means that a lot of good can be done.  Provisions could be beefed up and balanced.  A starting point for that might be master service agreements.  MSAs are a situation where there are also info security concerns, but there the customer is king, not pigeon.

As grist, I offer a couple of links:

A simple privacy policy with a rough (mine) taxonomy of the issues: http://privacy.commonaccord.org/index.php?action=source&file=Moynihan/Form/Privacy_Policy.md
Done from a form offered by Tim Moynihan, who is involved in Berkman's bitcoin/blockchain stuff. 

A bunch of corporate privacy policies, in pretty raw state:
http://privacy.commonaccord.org/index.php?action=list&file=Com/

Master Services Agreement (from a GE form):
http://source.commonaccord.org/index.php?action=source&file=/Service/Form/MasterServices_Form.md
(click on the link to [Service/Sec/PersonalData/PD_Sec.md]) (with another taxonomy)

(If materials seem to be scattered all over the place, it's (partly) because I've been working out ways to make text fully distributed, let folks do their own thing, yet allow it to converge.)

Thanks, Jim
 



On Sat, Sep 26, 2015 at 3:44 AM, Adrian Gropper <agropper@healthurl.com> wrote:
Eve's initiative on structuring the UMA use-cases from a business perspective made for a productive meeting. My take-away suggests these three branches for legal structure:

A - AS legal entity has access to the RO's data,
B - AS legal entity has no access to RO's data,
C - AS legal entity is the same as the RO because the RO built the AS

I think A, B, and C work well for both IoT and healthcare business models and there's no overlap between the three branches.

Adrian

On Fri, Sep 25, 2015 at 1:26 PM, James Hazard <james.g.hazard@gmail.com> wrote:
Since I can only approximate sanity, here is an example of a framework on which one could hang sane agreements.  This is just a stub with a few nuggets picked up in our discussions. 

(click on Document).  In the Document view, when you mouse-over a bit of text it shows a bit of metadata, the name of the property.  This can be expanded to include a link back to the source of the text and to show any difference vis-a-vis the chosen model.
 

A next step could be an outline (the top-level headings) of a good, real ToS-type agreement, with representations, pickles and mustard, which would provide a frame for provisions.  

The chain-of-text could run from UMA, or regulators or other well-meaning persons - through the business to the citizen (or from the citizen to the business if the citizen has her own tech).  

This example is kind of odd but shows the idea - the (unenacted) Consumer Privacy Bill of Rights flows to a charter and then to a privacy policy:

  



On Sep 25, 2015, at 6:26 PM, Eve Maler <eve@xmlgrrl.com> wrote:

  • Examine/confirm top meta-use cases
    • RS is concerned about outsourcing protection functions to AS
    • RO is concerned about the accuracy and success of granting access to RqP given incomplete trust and the intermediaries involved
  • Discuss/prioritize business models
    • Organizational consumer-facing access federation
    • Industry access federation
    • Free-love access federation
    • Other
  • Determine roughly what our outputs should look like
  • Develop a list of unknowns without which we can’t finish our work

Attending: Eve, Jon, Adrian, Jim, Thomas, Domenico, Dazza, Ann

  • Meta-use cases:

1. RS-AS: RS is concerned about outsourcing protection functions to AS.
2. RO-RqP: RO is concerned about the accuracy and success of granting access to RqP given incomplete trust and the intermediaries involved.

Are these the top pairwise relationships to be concerned about? Adrian is concerned about the case where the technology that is executing the RO’s instructions is sovereign — that is, RO=AS. The analogy with SSO/authentication-as-a-service breaks down when we get to this point, because authentication is a kind of reputation service, authenticating the RO’s identity. It has to be a third party. By contrast, the AS can be wholly "first-party”. Should we add a third item about this? Yes:

3. RO-AS: RO is concerned that the AS fully represent her, and thus seeks to be able to build (vs. run or outsource) an AS so that it will never need to "have a privacy policy” because it’s hers.

  • Business models:

1. Organizational consumer-facing access federation: Similar to the corporate consumer-facing identity federations of today. Enterprise E serves as both AS and IdP to its end-user customers, who are the ROs. RqPs might be customers as well, or also users with a more tenuous relationship to enterprise E. The RS’s and clients might be run by enterprise E, or possibly also by some partners P, who have been well vetted in advance and whose service and app relationships were set up statically. Each RO experiences the AS as covering the authorization of some fairly limited set of resources in their “online world” (e.g. vertical- or vendor-specific), rather than a potentially comprehensive set. The federation might or might not cross jurisdictional boundaries. Example: Government-to-citizen attribute-sharing and delegation platform with a single government-run AS.

2. Industry access federation: Somewhat similar to the social login identity federations of today. A variety of services and products SP find it valuable to standardize on a method of outsourcing authorization, and a few authorization players A have arisen that are willing to play the AS role, such that end-user ROs are able to choose, by (something approximating) free-market action, the AS they would like to use when engaging with each SP. However, there may be market forces that restrict the choices A presented at each SP among which an RO could choose, producing a “NASCAR effect". Options that are "RO-built/bought/run" are, as today, much less likely to be viable in the market, but there is no structural reason that they would be excluded. The environment is fairly heterogeneous, with any AS/RS/client matchup possibly representing three different organizations, but each required pairwise relationship is likely established in a static fashion, as today. Example: Consumer IoT marketplace with a few popular AS platforms to choose from (imagine WeMo etc.).

3. Free-love access federation: :-) An analogue to the Platonic ideal of identity federation oft-imagined today. All parties can meet and establish trust dynamically as required; for example, an UMA client can acquire OAuth client credentials at an AS at the moment of need, and so can an UMA RS, with any business concerns such as execution of terms of service handled dynamically. ROs can freely choose, build, buy, or run their own AS. Example: The desired end-state of the global healthcare market, with IoT and consumer elements mixed in.

The reason it’s “BLT” is not just because, Bacon!!!, but because business comes first! The draft NIST Privacy Risk Management Framework notes, very sensibly, that you must start with a business goal.

What business model do the HIEs of today represent? Are they focused on a single provider? They’re vertical-specific, regional, and voluntary on the part of the RS (hospital). They struggle mightily to get adoption and achieve a sustainability model. Under HIPAA, they decided to extend HIPAA to treat data aggregators (an HIE is one) as a business associate. This gives flexibility. There are about 80 HIEs around the country, and only NY (as far as we know) has enabled patient access. It’s the province of big hospitals. The HIE only stores identity information for patient matching. Data is exchanged through Direct messaging. An HIE registers encounters, and it manages consent. Eve suspects that HIEs anomalously reflect today’s US HIPAA regulations, and we’re building something specifically patient-centric. Further, that they are a special case of an industry access federation because they are exposing heterogeneous services.

We explored the industry access federation example a bit more by looking at SmartHomeDB.

#1 means you’re “on the plantation”. #2 means the data never even enters the plantation; it stays in its native environment, the way data can stay on a phone.

We agreed to focus first and foremost on #2 because it meets important UMA goals, requires legal support, and appears to be the critical model required for the IoT.

  • What should our outputs be?

Should we be developing sample pairwise agreements at the “client credentials issuance” stage because the terms and conditions at that stage are so important? There’s a B2B stage, and a B2C stage. The opportunity to issue those credentials always seems to come with a “gate” that has business agreements associated with it.

AI: Dazza, with Eve as backup: Bring a source of contract terms for getting OAuth client credentials.

AI: Jon: Bring preliminary thoughts on IoT liability tensions.

AI: Jim: Pose an answer to the question “ What would a sane, brilliant, non-powerless consumer, with some bargaining power (or friends at the EFF and Justice Department) expect from an agreement?”

AI: Dazza: Create a “business models page” on the wiki, numbering the business models.

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma


_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma




--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/



--
@commonaccord