Information Sharing GROUP Teleconference
Table of Contents | ||||||||
---|---|---|---|---|---|---|---|---|
|
Date and Time
- Date: 7th December 2009
- Time: 9 PDT | 12 EDT | 5pm UK
Attendees
- Joe Andrieu (voting)
- Iain Henderson (voting)
- Judi Clark (voting)
- Eve Maler (voting)
- Mark Lizar (voting)
- Joni (staff)
Apologies
- Henrik
Agenda
- Attendance
- Prior Action Item Review
- UMA synchronization
- New Business
- Engagement Model
- Action Item Review
Minutes
1. Attendance
(above)
2. Prior Action Items
Iain and judi will meet to tidy up minutes. Iain will set up meeting time. Joni and Iain took care of Charter.
3. UMA Synchronization
Eve & group working toward (self-imposed) deadline for specs and scenarios, protocols to centralize authorization. Lots of problems to solve, started to tackle: UMA has 4 parties: authorizing user, host of protected resources, authorizing manager, requestors of resources. Basic service to service authentication, using oAuth & other tech (Strawman 1). Terms negotiation (at tech level) based on claims: info card-based mechanism not flexible or simple enough to meet UMA needs. Paul & Eve presented "Road to Claims 2.0" methodology, simple enough to appeal to web developers & how to do tricky things re: asking claims that current tech doesnt represent. JSON - javascript friendly XML representation mechanism. Assertions & id tokens (XML) matching format. Claims (JSON) get response: signatures and info, following satisfactory assurances.
...
Categories for claims (Joe): 2 diff orthogonal areas: policy ways to use info. Big diff between known 3rd party and trust framework. Reference to whitelist (AMA-listed doctor) as well as whitelist (AMA). Discussion on other use case: anyone with these open IDs (other system) - trusting the (levels of) indirected trust, federation (Sally's husband in diff ID guises). Issuer: one entity (BBB) delegated as top level certifying authority. Mark: context engine: relationships and reference points. Joe: distinction: know semantics of assertion (indiv vs corp). On self-asserted side: what's semantic diff between clear-text field and signed info? Eve: focus on ID, e.g., connecting on skype but outer context or other info provided may give "leap of faith" authentication. Discussion on (skype/service) request matching up to person (correlating is independent of trusted issuer). ID providers (skype, OpenID, assurance framework) is not self-asserted. ID card that's self-issued (signed or not) has no power -- does issuer have any authority for user, whether user believes that issuer. See Eve's claims handling examples.
4. New Business
none
5. Engagement Model
not covered in this call
6. Action Item Review
Iain and Judi re: past minutes
Next Meeting
14 December 2009
9am Pacific, Midday Eastern, 5pm UK
Skype: +9900827042954214
US Dial-In: +1-201-793-9022
UK Dial-In: +44 (0) 8454018081
Room Code: 2954214
...