UMA telecon 2013-05-02

Date and Time

• Focus meeting on Thursday, May 2, at 9am PT (time chart)
  
  • Skype: +99051000000481
  • US: +1-805-309-2350 (other international dial-in lines available) | Room Code: 178-2540

Agenda

• (Get on join.me)
• Reminder: No meeting next week due to IIW/IDESG!
• Action item review
• Review IIW activity plans and status
• Work on OpenID Connect optimization opportunity slide deck (to be displayed on screen)
• Threat model discussion (see email thread)
• AOB

Minutes

Action item review

Done. See that page for details.

IIW planning

We're a little concerned about conflicting sessions at IIW! Eve will edit the "OIC optimization opportunities" slide deck by Saturday, as well as Keith's and Thomas's slides. Mike Schwartz is planning to demo Ox's new UX for UMA at IIW.

Optimization opportunities

Should we prioritize RS/AS colocation (issue 67) in the list of OOs? Adrian notes that secure centralized logging is a requirement for HIPAA in a number of circumstances, perhaps including this one. If a single company wants to "onboard" multiple RSs (apps), this could be useful. Let's ask people to identify their level of interest in this, supplying real-world scenarios, at IIW.

We think "same-app Alice-to-Bob sharing" is a really key one (RS = C).

OIC is focusing mostly on the latest Implementor's Draft. We think the backwards-incompatible changes have really slowed down. There have been some changes that track changes in JOSE, and also dynamic registration. There have been a few parameter name changes.

Threat model

Domenico proposes a way for the client to sign the RPT, in order to bind the client and Bob.

George posits that the RPT could contain two pieces of data: who it was issued to, and who it's intended for. But this doesn't have a strong binding. If the AS could add its signature to the innards of the RPT, and the client could sign the RPT as a whole, the RS is now in a position to verify the binding all the way through. But if the RPT – which is still a bearer token – gets stolen by a MITM and replayed, then the protections don't help as much. Then you're back to time validity limitations to mitigate this concern.

What if we added a temporary-use "ticket" that correlates to the same client, a la our permission ticket? Or what if we used a kind of "client TLS"? If we use server-side SSL everywhere and then use Domenico's model, this seems to cover 80-90% of use cases. If you need more, then go with mutual SSL and call it a day. 

Google has been doing some research into how to bind cookies to a given browser. "Channel ID" is the name of the work. Could we just rely on efforts like this and on people's ability to define their own RPT profiles that aren't simply opaque bearer tokens? Since the RS already has a way to have the AS introspect the token presented by the client, then asking the client to add something to its access attempt message would be natural in that case. Maybe sticking the existing bearer-profiled RPT into a JWT and signing it (making it JWS) would be sufficient for anyone who needed that. Since in the existing profile's case, the AS is already doing all of the token introspection heavy lifting, that could be leveraged for client signature verification too. (This still doesn't prevent MITM stealing and replay, though timely signing and timing controls on the receiving side can help.)

AI: Thomas: Flesh out the last security considerations bullet to provide additional context about solutions that are stronger but not entirely getting away from "bearer token" status.

Voluntary identifiers

Adrian remarks that "identifiers for data holders" is something ONC/HHS is working on. Similarly to a W-9 form that tells an employee how the employer will report things to the government, they're talking about patients supplying a voluntary ID so that they can learn how their stuff is going to be aggregated and shared across the Internet. This mitigates risks of secret surveillance. Does it make sense for UMA to consider the implications of a voluntary identifier like this? Key goals here are "voluntary" and "transparent".

When a person registers for a health service, e.g., onboarding as a patient at a new doctor's practice (filling out all those forms and consenting to lots of boilerplate), the Patient Privacy Rights folks want people to be able to specify the ID that would be used for surveillance/correlation/aggregation. Where should this ID come from in an UMA-enabled environment? Adrian is thinking it should come from the person's AS, vs. an IdP. Eve comments: In this case, the "identifier" is really a trusted user claim. People could give false tax IDs to employers, or false SSNs to doctor's offices. George notes: In OpenID, if the system exposes to the user the pairwise pseudonymous identifier, there's a concept of an affiliation among multiple parties that know the federated ID. So maybe there's something here that could be useful. The auditability by the individual of what's done under a certain identifier is powerful.

If the identifier is an email address, then there's a natural means of confirmation of binding with that person, since you can do a confirmation loop. And in fact, email addresses work great for the purposes above, since you can do the emailhandle+specialid@domain.com. So email addresses aren't entirely horrible at this.

Attendees

• Eve
• Andrew
• Domenico
• Keith
• Adrian
• George
• Maciej

Regrets:

• Alam
• Susan

Next Meetings

• No meeting on Thursday, May 9 due to IIW/IDESG
• Focus meeting on Thursday, May 16, at 9am PT (time chart)
• Focus meeting on Thursday, May 22, at 9am PT (time chart)
• All-hands meeting on Thursday, May 30, at 9am PT (time chart) - leadership elections: chair, vice-chair