[WG-UMA] Progress on lexicon/legal issues

[Eve Maler]

Below are the notes from our very good conversation with TomS yesterday.  I would summarize the results and next steps as follows:

Enforceability: 

- UMA isn't particularly special wrt other online technologies in its enforceability properties.

- Services implementing UMA endpoints will need to apply the same types of operational controls they would to a user clicking "I Agree" today.

- The binding of a requesting party to a claim-based agreement has some interesting wrinkles, more related to the use case than the protocol.

Claims use cases: 

- The matrix of options is interesting as an analytical tool for "showing our work" but we shouldn't make everyone buy into all of it. :-)

- For simplicity reasons, we need to whittle down the options for who the requesting party should be.

- One should be "person-to-service" (for OAuth-like and VRM-like use cases where it's for either Alice's or some company's ultimate benefit).

- The other should be "person-to-person" (for "social sharing" use cases where Bob is at the other end).

- We identified a couple of juicy use cases below that would be ideal to capture in our Scenarios document. (TomH??)

"The diagram": 

- The diagram is helpful analytically, but needs more clarity and possibly needs to be a higher-level summary with a few drill-down diagrams.

- Another diagram that shows the chain of agreements being built over time would be particularly helpful for legal eagles.

- I'll work on these with Domenico.

- They will eventually find a home in the new technical report I'll put together, which TomS is interested to review.

Please feel free to comment. Thanks, all!

Eve

Begin forwarded message:

From: Eve Maler <e...@xmlgrrl.com>

Date: 1 April 2010 1:14:12 PM PDT

To: Eve Maler <e...@xmlgrrl.com>

Cc: Mark Lizar <ma...@smartspecies.com>, Thomas Hardjono <hard...@MIT.EDU>, Tom Holodnik <Tom_Ho...@intuit.com>, Maciej Machulak <m.p.ma...@newcastle.ac.uk>, Paul Bryan <em...@pbryan.net>, Tom Smedinghoff <smedi...@wildman.com>

Subject: Notes from meeting with TomS

Attending: Eve, TomS, Maciej, Thomas, TomH, Louis Monvoisin, Mark Lizar

Thanks, all!

Eve

On 1 Apr 2010, at 10:56 AM, Eve Maler wrote:

+1-408-376-7229 or +1-866-684-3229, mtg ID 345-6756

Here's a tentative agenda, working from http://kantarainitiative.org/confluence/display/uma/Lexicon:

- Clarifying the differences between software and services (tools) vs. those who run and use services (may be held legally responsible)

We're clear on the distinction, but the dark-blue boxes mislead by saying "service" all over the place. Maybe we need to remove that word? And we should maybe provide a legend.

- The limits of legal responsibility for the actions of tools and whether this should impact UMA or is a generic problem

E.g., a person using MSFT Word isn't really responsible for errors in the coding of Word. Machines/software/"electronic agents" can arrange for a person to enter into a valid contract, e.g. in the case when a person interacts with Amazon.com to buy something. When a person books first-class travel to Paris with United for $10, is United liable to live up to that contract? Real example: State Farm sent a person a notice that their insurance policy wouldn't be renewed by snail mail, but then the person got an email offering a renewal link that the person used to get a renewed policy later in the mail, and then the person got into an accident. The court held State Farm to the renewed contract.

- Legal enforceability of claims in general

Because natural persons may not always be technically sophisticated, when they use an AM service or host service or requester service in the usual fashion, would we hold them liable for confusing interfaces, bugs, etc.? We are going to assume that the pairwise "TOS" interfaces between humans and companies that run services will govern those questions and that it's not really an UMA-specific problem. Some of those would end up in the courts.

Eve's presumption/hope is that, since clicking "I Agree" to accept site TOS's is enforceable, then requesting parties should be similarly bound, right?  Tom says yes, but sometimes there are mitigating factors of "procedural unconscionability" that might invalidate some of the terms. E.g., if the agreement uses the laws of the state of California but the user is in Chicago and can't easily travel to California, or if any action in court requires a $5000 filing fee, these might be considered so unreasonable that they don't apply.  "Surprise terms" might not be enforceable. So similarly, requesting parties are only bound to terms they agree to that meet these standards.

Is it enforceable to require the equivalent of clicking an "I Agree" button on the requester side?  Yes, if the agreement can be recorded and bound to the party who signed it in the same fashion as done today. So in cases of weak or nonexistent requesting-party identification over at the AM, the case for enforcement might get weaker over at the host. Then again, if you ask all requesters simply to agree to the CC licensing terms on that protected resource, even without identifying themselves uniquely, then it may be possible to show that every requester would have had to agree to this to get access. There was a real-life case with AOL that turned on this distinction.

TomH asks: There are IRS rules about how tax data is used, and this may affect the responsibilities of the host of that data. How does this impact the UMA situation? A person can lodge _their own_ tax data anywhere they like. But a tax preparer, or an employer, or a healthcare professional, who is hosting the data of the authorizing user would likely be regulated.

Let's say Alice is sending her daughter to UCLA. To determine eligibility for aid, UCLA asks to see Alice's tax return. Alice instructs her AM to let her host of tax return data give access to Bob at UCLA.  Is it okay to say that anyone at the admissions department at UCLA can see it, or just Bob? TomS guesses that the IRS doesn't care. You can tell your tax preparer to give your return to anyone you want. The bigger question is, what scope of authorization has been conveyed, and how can it be enforced? This is indeed an UMA question.

This is very similar to how we might want a doctor's office to forward medical test results to a specialist, or information to an insurance company  for reimbursement. In the medical case, HIPAA and similar laws come into play.  Eve's hope is that we can consider these to be "mandatory" with respect to the UMA protection placed on the resource, which is merely "discretionary". A host may always be subject to other laws, regulations, subpeonas for release of data, etc., that take precedence but are entirely "out of band" with respect to UMA.

Louis introduces the notion of "vicarious liability". (Wow.) There may be a chain of liability that extends through to a different party. Given that there's a whole chain of responsibility from Alice, through the AM service, through the host service, through the requester service, and to a requesting party, damages for liability may be spread in some proportion among them!

AI: Eve to try and make a diagram that shows "parties" in a chain of interaction.

- Explore person-to-self (with intermediary services) vs. person-to-service (on behalf of self)
- Explore person-to-person (with intermediary services) vs. person-to-service (on behalf of other person)

Let's use the example of Alice sharing a calendar hosted on Calgoo.com with Bob, who is using Google Calendar to manage subscriptions. How to decide who to make the requesting party? Likely Alice would ask both Bob and Google Calendar to adhere to the same confidentiality rules, but then other claims-required might apply only to Bob (like "You must be over 21") or only to Google Calendar (like "You must not let other users besides Bob see this data without other authorization").

TomS's intuition is that Alice-to-Bob sharing should treat Google Calendar as something like a "common carrier". Bob can't reasonably promise anything about Google Calendar's bad behavior, e.g. if there's an insider breach and someone Google wants to stalk Alice. Maybe we can look to the Electronic Communications Privacy Act for imposing reasonable liability on Google. (We should acknowledge that the TOS he has with Google is likely to absolve Google of all liability!)

Based on this analysis, Eve proposes that we advocate (require?) only the following options:

- Person-to-service (claims required from company running the requesting-side service) whenever Alice herself is involved on the requesting end

- Person-to-person (claims required from Bob) whenever Bob is involved on the requesting end

We suspect that the "empowerment" goals around users and vendors really impacts the person-to-service use cases more (as previously stated in an UMA WG call), and indeed, that we need to get experience in the wild to understand how the claims framework could be used effectively.

- Legal enforceability requirements on affirmative vs. promissory claims

Affirmative claims can only be assessed to be true at the particular point in time when they were made. Promissory claims don't generally have this constraint.

Audit logs and records of these agreements are going to be a big part of the enforceability picture. Whatever standard is adhered to by companies with websites that have "I Agree" (clear offering of terms, secured logs, etc.) is the standard that UMA endpoints would have to adhere to for maximum enforceability.

Eve Maler

e...@xmlgrrl.com

http://www.xmlgrrl.com/blog

Eve Maler

e...@xmlgrrl.com

http://www.xmlgrrl.com/blog