Attending: Eve, Jon, Dazza, Mark, Tom, Adrian, Jeff S The wg-uma GitHub area has a wiki https://github.com/KantaraInitiative/wg-uma/wiki that Dazza has been populating. Work through Adrian email thread to discuss UMA flow and use cases Walk through an UMA demonstration? (Eve) Discuss consent receipts and logging — how do they map to use cases? See consent receipt generator demo? (Mark) How many more use cases do we really need? a lot? a few? none? Discuss licensure vs. contract (if time?) We walked through the UMA FAQ descriptions of the UMA flow. An autonomous web service client can often be in a data broker role: an institution where the RO doesn’t have a login. What about where “data rights ownership” resides in multiple parties? UMA the technology settled on a simplification where only a single entity (meaning a hunk of software or operator of same) can be an RO. But in reality, multiple parties (meaning persons or non-person entities that can do things like sign contracts) could have rights. Adrian says “There’s only one Alice”. Are we focusing exclusively, or primarily, on “Alice” use cases? UMA was originally intended to focus first and foremost on the individual as an RO, which is why our BO spec https://docs.kantarainitiative.org/uma/draft-uma-trust.html points to NSTIC (while slightly debugging its definition of Individual). Action item/issue: We should circle back around to revising the definitions of party/entity/role etc. Look at the BO spec https://docs.kantarainitiative.org/uma/draft-uma-trust.html for background. The notion of data sharing with third parties is not very well covered in law, so UMA is significant in this area. The proposed EU Data Protection Law revisions do seem to have some relevance here, though. And this is where Consent Receipts are also relevant. Dazza suggests that the ISO 29100 statutory privacy roles https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Use-Cases,-Roles... have relevance here, but Adrian isn’t so sure. Analysis of Alice-to-Alice N use case: The OAuth model is “pairwise” between each service and client app. UMA, by contrast, allows Alice to aggregate the records of all of her consents (and ultimately receipts of her consents). “Accounting for Disclosures” (A4D) is a HIPAA term of art; think of this just as a record of the consents, not as the “CDC" point. Ultimately, the use cases can blend; each is just meant to highlight a few aspects of desired features but they’re not mutually exclusive. How would we map the people and organizations named to roles? Would one of the EHRs be something like a Microsoft HealthVault? Where would a physician come into play? Adrian has kept PCPs and personal health records (PHRs) out of this use case for simplicity. Adrian’s “Release of Information” (ROI) form goes into detail about the “who to sue” question. In the US, frequently a PCP has a hospital affiliation, and the hospital uses a SaaS product run by an EHR vendor like Cerner. Eve has a login to evergreenhealth.cerner.com http://evergreenhealth.cerner.com/. She can use the (proprietary but UMA-like) portal to share the allergy portion of her health record with her husband. In this case, Cerner is a “Business Associate” of the institution. What Eve calls “figuring out who to sue” is what the pros would call “structuring the transaction”. When using a standard that allows multiple parties to hook up and use others for authorization, this is the goal. Next time: Accelerating on the use cases, and mapping to consent receipts, given our deeper understanding. Today counts as excellent progress — thanks, all! Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com