We briefly discussed the UMA WG's IPR policy and its implications.
Eve will revise the script very soon, and Eve and Dazza will be the voices. Adrian is planning to attend the VRM/Personal Cloud day. They're planning to show the T's and C's documentary at a theater nearby (tix are $11). Let's see if we can wrap up the video in time for the VRM/PCloud/IIW week!
Eve has reached out to both Ann Cavoukian (PbD) and Peter Brown (PMRM), and Dawn Jutla, who is a common thread between the efforts.
Adrian notes that it would be useful to check the healthcare use case against the new paper (Adrian is the coauthor of the IDESG healthcare use case). It currently does mention two healthcare touchpoints. Sal mentions the privacy committee that's part of the IDESG: does it make sense to connect with those folks? He'll drop a note to that group to point them to this material. UMAnitarians in general should feel free to spread the word about the paper to communities of interest.
What's the use case again? The AS may want to be a dashboard, do analytics over user data/content, etc. The AS may also want to do notifications to the RO, so as we centralize functionality into the AS, users will prefer to have the filtering capability of the AS rather than dealing with, say, seven different patient portals. A major justification for the AS is this filtering functionality. AS=C is then just another similar case to RS=C, which we glancingly talked about in the Project hData scenario but otherwise haven't discussed heavily as an optimization opportunity.
Eve proposes a design principle of "Even if an UMA-conforming application can shortcut communications with itself because it is serving in two UMA roles, it must still generate artifacts that are UMA-conforming from the perspective of the rest of the entities it interacts with". It could be paired with recommendations ("SHOULDs" etc.) in the spec and also AS configuration data switches, which can all tie to unique binding obligations as appropriate.
Thomas and Eve discussed a little bit about how base UMA only solves for claims-based authorization, not for "identity". So the magic is all in the policies and any claims gathered. Okay, then, what if Alice's policies over the resource sets in question require claims-gathering? Can/should the AS literally gather claims from itself?? It doesn't seem possible. So instead would we have to get into the business of standardizing audit logging so that there's some externally observable artifact about this action? Dan wonders if this is dictating too much about the implementation. What if we just did something like RECOMMEND audit logging of such actions? Adrian points to the Accounting of Disclosures standard in the HIPAA world, which recommends that the log include links so that the patient can choose to click the link and see the information that was actually shared. This enables the client not to store the information, but point to it. And Eve points to the new F-Ticks proposal for an identity federation log format. This seems to support Dan's point about not overdetermining the answer. Different implementations and different access federation communities may have their own designs on this question.
Eve's "design bias" is to avoid making all the HTTP-based messaging in the spec optional, but rather to create packages of non-on-the-wire interactions that match to optimization use cases. This is because otherwise we might end up with every single message flow being optional to expose on the wire! Dan is concerned that this approach is going too far. However, if there is a tie-in to binding obligations in every case, maybe that keeps viability of the approach. Are these "optimization profiles"? Andrew proposes an alternative principle: Whenever it's important to have an external observer, the message must go out on the wire. Dan elucidates, "When in doubt, send it out to 127.0.0.1."
What are all the possible x-as-y use cases? Can we actually list them all?
All deferred.
Regrets: