UMA telecon 2013-10-03

Owned by Eve Maler
Last updated: Oct 08, 2013

UMA telecon 2013-10-03

Date and Time

Agenda

  • Logistics for next two calls: chair pro tem, dial-in, notes taker
  • Demo video status (rough-cut)
  • Privacy/PbD status (white paper)
  • AS=C use case discussion (previous notes)
  • Resource descriptions for user attribute retrieval (email thread)
  • SAML IdP+UMA attribute release discussion (email thread)
  • Field interop feature test issues if time
  • AOB

Minutes

Logistics and other

We briefly discussed the UMA WG's IPR policy and its implications.

Demo video status (rough-cut)

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!

Privacy/PbD status (white paper)

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.

AS=C use case discussion (previous notes)

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." (smile)

What are all the possible x-as-y use cases? Can we actually list them all?

  • AS-as-C
    • Client credentials issuance
    • AAT issuance
    • RPT issuance
    • Authorization data issuance
    • Resource access
  • RS-as-C
    • Resource access? The RS already has its own native access to whatever resources it's authoritative for, so maybe this one is meaningless. E.g., no one demands that Flickr prove it has legitimate access to your Flickr-hosted photos.
    • We need to be careful to differentiate between RS-as-its-own-C (seems trivial) and RS-as-C-to-other-RSs (the Project hData case) and RS-as-C-to-some-other-RO's-data in a multitenant situation.
  • AS-as-RS
    • PAT issuance
    • Resource set registration
  • RO-as-RqP
    • ?

Resource descriptions for user attribute retrieval (email thread)

SAML IdP+UMA attribute release discussion (email thread)

Field interop feature test issues if time

All deferred.

Attendees

  • Eve
  • Andrew
  • Adrian
  • Thomas
  • Domenico
  • Dan
  • Sal
  • Lukasz

Regrets:

  • George
  • Maciej

Next Meetings

  • Focus meeting on Thursday, October 10, at 9am PT (time chart) - Eve regrets, Thomas is chair pro tem
  • Focus meeting on Thursday, October 17, at 9am PT (time chart) - Eve regrets, Thomas is chair pro tem (IDESG is happening Oct 15/16)
  • Focus meeting on Thursday, October 24, at 9am PT (time chart) - note that UK goes off summer time on Oct 27
  • All-hands meeting on Thursday, October 31, at 9am PT (time chart) - note that US goes off summer time on Nov 3
  • Interop event at MIT on Oct 31-Nov 1 (date and location may change)

Â