Quorum: 10 of 19.
Quorum was achieved.
Minutes of 2009-12-03 APPROVED.
New AIs collected during the meeting:
The criteria are:
Mike: "If Staplers behaves badly (gives out her data against her rules or allows a data breach to occur), she wants to be able to prove so – in court, if necessary." should be out of scope. Paul: Agrees that it should be out of scope for the protocol to make this literally/technically provable, but wants to consider the terms as an agreement. That is, the terms and the requester's agreement should be admissible in court somehow.
Mike: So is non-repudiation in scope? Eve: "Deep" non-repudiation (with key escrow etc.) is too hard. Mike: But how do we protect Staplers against Maya? What if Maya changed the terms after Staplers agreed? Paul: Agreed that we do have to provide the option to make claims independently verifiable, where this is what contracting parties want. Mike: This might end up being a matter of security considerations advice where we say the AM has to log things appropriately. Eve: This may want to be a new requirement somehow.
David: The trend in Europe is not to accept systems that won't provide this level of verifiability, e.g. around user credit card info. George: We're talking about two different kinds of claims here – there's user information that might be stored in a "personal datastore", and there's claims used to achieve an UMA access agreement.
Perhaps we can illustrate this scenario with Dom's multiple-hosts picture. We will try and do the disposition of this scenario next week.
We discussed Eve's notion of a "relationship manager" application, which at a minimum implements an AM endpoint but: (a) has to implement a number of UX functions to interface with the user, (b) has to implement a number of internal functions such as event logging that are not "visible" to protocols, and (c) may in addition implement other UMA endpoints, such as a Host and even a Requester! The concept of a relationship manager is discussed more in this blog post. Is relationship manager the right term for this? This is still not decided (it came up in this week's Kantara Info Sharing call as well), but we do need to account for it in at least one of our terminology diagrams, so that we can discuss on-board Hosts that might help package several multi-hosted resources.
Recap: Paul couldn't find an expressive enough format in existing work that could avoid a "claims explosion" to cover, for example, every possible age and age range. (Age information could be an "UMA access agreement" claim, e.g., if you want to ensure that the requesting party is old enough to receive adult material.) This is why he delved into the parameter mechanism.
His current approach uses JSON, and he's feeling more and more confirmed in this approach. JSON structures can be serialized into objects in numerous languages with no ambiguity, and they are widely supported. An alternative could have been a flat format, but then some structured info would have to be crammed into flat string values. The other extreme would be XML, which isn't that "extreme" really, but it would introduce ambiguity due to impedance mismatches with programming data structures (this is why JSON was invented, after all).
Due to the conversations with David on the list, Paul has added a notion of "qualifications" on claims, including "critical" vs. "advisory" ones. This is akin to SAML's notion of Conditions vs. Advice.
The CouchDB folks have come up with a straightforward method of normalizing and signing JSON structures, which Paul has been inclined to use. We pinged the WRAP list to see what their plans are around JSON web tokens, and it could be that their alternative is better.
Bill: Do we plan to use the same mechanism for promises? Paul: Yes. Eve: Expects that most Internet-scale use cases will have a simple structure that just mentions the URL of the standard agreement terms that you're promising. E.g., Creative Commons copyright licenses could be used today – without having to invent any new terms! – to ensure that a requester promises to adhere to your CC terms before it gets access to your CC-licensed Flickr photo.
Paul proposes to use an extra-simple structure that adheres to "one statement per claim". This would mean that it's easier for a requester to subset claims coming from an original issuer before remanding them to the AM (which is the "relying party" in this case).
If the protected resource is a survey, and you want to limit takers of the survey to people who are between the ages of 18 and 35, the AM might demand a claim from the requester saying that the requesting party is between those ages. Or if the protected resource is some adult material, the AM might demand a claim from the requester saying that the requesting party is over 18 or 21. This is akin to the "identity oracle" concept that Bob Blakley has proposed; the data is "cooked" to achieve minimal disclosure before being released, rather than the "raw" birthdate being shared.
Eve: This is where a "relationship manager" application that houses not only an AM endpoint but also a Requester endpoint could help mediate the providing of such verified information. It could even have a parallel process to the UMA allowance for real-time consent by authorizing users, to let requesting parties consent to providing "UMA access agreement" claims.