UMA telecon 2013-01-31
Date and Time
- All-hands meeting on Thursday, 31 Jan 2013, at 9am PT (time chart)
- Skype: +99051000000481
- US: +1-805-309-2350 (other international dial-in lines available) | Room Code: 178-2540
- Roll call
- Approval of minutes
- Action item review
- Admin: chairs pro tem for Feb 7 and Feb 14?
- Event/schedule discussion
- Report from MIT Legal Hackathon
- Report from the Personal Clouds gathering
- "UMA for Healthcare" planning meetings leading up to Feb 21 Cloud Heathcare meetup: Jan 31 10-11am PT enough?
- IETF 86 in March
- Podcast planning
- Webinars: plan another one?
- Tweet jams: plan another one?
- ABBI doc: comment formally?
- Spiral diagram comments
- Threat model review and publication planning: separate doc or integrated into core doc?
Action item review
Quorum was achieved.
Approval of minutes
MOTION: Approve minutes of UMA telecon 2012-12-20 and reading into today's minutes the following past focus meetings: UMA telecon 2013-01-24, UMA telecon 2013-01-17, UMA telecon 2013-01-10, and UMA telecon 2013-01-03. APPROVED by unanimous consent.
Action item review
The Italian Wikipedia entry has been updated! Riccardo has agreed to edit the Spanish one. Eve is willing to do the English one.
No updated status on any of the other existing AIs.
Admin: chairs pro tem for Feb 7 and Feb 14?
Maciej can cover Feb 14. Let's cancel Feb 7, and instead everyone can work on their action items.
- Report from MIT Legal Hackathon: It was a very cool event. Thomas, Domenico, Eve, and Sal all attended parts; Thomas and Eve presented. Eve found it to be a great opportunity to share UMA itself and also the Binding Obligations mechanism. The "UMA buzz" continued in the following days. Dazza intends to follow up with Maciej and Mike re POCs for "terms of authorization".
- #id140 tweet jam: Eve participated and mentioned the OAuth Resource Set Registration work around interoperable scopes.
- Report from the Personal Clouds gathering: no one on the call attended.
- "UMA for Healthcare" planning meetings leading up to Feb 21 Cloud Healthcare meetup: Sal and Adrian will get together in person next Monday to push this forward, and will report back. Eve describes the Trulioo and Virtrue models of social identity verification, wherein the user – for the first time – becomes a direct authorizer of access to sensitive personal data, e.g. for the purpose of applying for a job. This can apply to the patient-centric health data sharing model when you add UMA, since the patient needs no login at the "relying party", and the patient has the potential for centralizing their management of all health data sharing. Sal and Adrian can look at the other existing case studies for inspiration, as well as our meeting notes from 2012-11-29. Adrian notes that if UMA can become a standard component for accounting for disclosures (including breaches?), that would be a huge benefit – in other words, its capacity for auditability of access is key.
- IETF 86 in March: We don't know if any UMAnitarians will be in attendance.
- Podcast planning: Dazza, Keith, and Adrian have expressed interest in being interviewed in a podcast series. We hope Maciej, Mike, and Phil W will as well. Let's explore evening hours (ET) for a weekly podcast calendar time slot.
- Webinars: plan another one? No enthusiasm for another one anytime soon.
- Tweet jams: plan another one? No enthusiasm for another one anytime soon.
- ABBI doc: comment formally? There's no formal process for commenting, but there's an opportunity to present for 15-20 minutes, or simply submit a document (which might not be looked at). Sal and Adrian will discuss this opportunity on Monday. One thing they're considering is the relationship between X.509 certificates and OAuth (and by extension UMA). Are these just server certificates? If so, it may be orthogonal. But it appears that these certificates identify individuals. What about authenticating into OAuth processes through signed JWTs (a la Google Service Accounts)? This could still be a relatively trivial matter.
- Kantara event at RSA: We should keep tabs on this; if UMAnitarians will be at RSA they should consider attending. Sal and Eve will be at RSA.
- IDESG in Arizona: This is next week. Sal isn't going. Adrian might attend some of the healthcare topics remotely; he represents Patient Privacy Rights at that table.
- PPR summit early June in DC: Attendance is free; it's at Georgetown Law School.
It would be very valuable for us to have some "standard" UMA slide decks for various people to use in many venues.
AI: Eve: Create standard UMA slide deck(s). (Sal will review.)
Spiral diagram comments
Arrowheads: Why did we take them off? It's because the verbs are meant to help us tell a story, and there are stories for both directions for all verbs.
- Re trust: How about negotiate? The story around this is that the AS is the RO's proxy (has "authorization power of attorney"), and offers terms on her behalf; the RqP is present in the negotiation by design and has the opportunity (depending on the claims profile in use) to negotiate back, or at a minimum, consider accepting the terms offered.
- The labels for the entities should be lowercase.
- The RO and RqP should have icons for "people" (Alice and Bob).
- We need an alternative version that uses the uppercase Party names vs. the lowercase entity names.
- Domenico should "sign" his diagrams! A domcat avatar?
Threat model review and publication planning: separate doc or integrated into core doc?
We discussed Domenico's point about a malicious party impersonating Bob. Since Bob isn't Alice – he's a third party – at the time of RPT issuance (assuming "bearer" profile), Alice (through the AS) could set policies to demand more claims from more or stronger sources to ensure it's really Bob who initially gets the token; additionally, if the implicit grant flow is used, Bob is exposed to the token. At time of RPT usage, it's possible that Bob could maliciously pass the token off to other third parties. There are several mitigation strategies available:
- Weak: Binding Obligations: RqP has the obligation to represent the legitimate bearer.
- Stronger: Create an UMA profile that disallows the use of the implicit flow.
- Strong-ish: The AS and the RO put in place time-to-live strategies around token life, claim expiration, etc.
- Very strong: Create an RPT profile that requires holder-of-key.
As of 27 Nov 2012, quorum is 6 of 10.