Attending: Eve, Scott, Adrian, Dazza, Jon, Mark, Jim, Thomas, Tim Our schedule and deadline are meant to be a forcing function to align with UMA V1.0’s and V1.0.1’s needs. Eve read the draft mission statement in italic: 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. What does “transactional” mean here? It’s probably not a term of art, just a word. Scott could see substituting “interaction”, but it’s not strictly necessary. Transactions imply some formalism. When you have intermediation without being able to monitor the transaction fully, you have a problem. He has seen problems in supply chains where there are no measurements the middle. Reliability is a goal. The parties and intermediations need to be listed and understood. Eve described the overall goal of the exercise, from her perspective, is giving comfort to those interested in deploying UMA — in any size of “cloud” — that any sets of parties involved who have misaligned interests can nonetheless have enforceable and predictable ways to do it. Adrian’s take is a little different, but related: For those parties in a potential ecosystem who are *not* interested, he wants to create some kind of “safe harbor” that shifts liability appropriately away so that they will be willing to play along. He thinks these will be the resource servers in healthcare. Scott says this is two ways of expressing the same thing. Liability is just cost. Standardization of result, such as standard contracts, is one of the ways, to reduce such costs. Accelerate adoption! Reduce inhibitors! Dazza notes that the UETA, with the essential notion of actors and actions, is relevant. At the end of the day, you may have hundreds of intermediaries. A good place to start is the use cases, such as those Adrian sent. The selection of use cases inherently surfaces the parties of interest to us, and sets the prevailing context. Enumerating the transactional relationships is something we’ll have to do. What would deliverables look like to meet these goals, in order to be most effective? It may be too early for this. What makes a good use case? Generic UMA use cases count, as well as “things going wrong” use cases. These are like the “negative tests” in software testing. And we need success and failure conditions. In fact, all of the warnings you see on consumer goods are the result of something having gone wrong. (“Do not use this toaster while sleeping.” Samples: http://idiot-dog.com/disclaimer.html :-) Mark notes that the MVCR (Consent Receipt) work is getting to V0.7. There are some strong relationships here. Consent receipts are a species of transaction receipt, and since UMA is bristling with transactions, there are a lot of opportunities for receipts. If you add consent (a consent record) to a transaction, you can bind them. Adrian connects this to his use case that mentions “accounting for disclosures”, which Alice would want to hang onto for dear life, since it’s the only evidence that her data was shared — similarly to a confirmation number received when travel plans are changed. The correspondence to the logs of the servers where their own liability gets protected is a key element. Mark remarks that different UMA scenarios along the lines of “who owns the data” (at the resource server) may be an important dividing line. Adrian dislikes “data ownership”, other than RTBF. Scott thinks “data ownership” is a nonstarter, but “data rights ownership” could be workable. Next steps: - Anoint Dazza our GitHub wiki master — thank you, Dazza! - Begin use case collection and label them on wiki with “legal-*” labels for emergent categorization . AI: Eve, Adrian, and Mark especially: Contribute starter use cases . AI: Dazza: Explain in email how we engage on the wiki - Agenda for next time: . Remedial UMA flow explanation . Use case discussion and logging/receipts and data rights ownership . Licensure vs. contract Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com