Information Sharing GROUP Teleconference

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

1. Attendance
2. Prior Action Item Review
3. UMA synchronization
   • null scenario terms
   • ID scenario terms
4. New Business
5. Engagement Model
6. 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, requesters 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 representation that can map to XML but doesn't have XML's mismatch to programming data structures. Claims request (in JSON) gets claims (in JSON) in response: proposal includes how to handle signatures to achieve third-party-asserted claims where necessary.

UMA is sketching out basic scenarios for terms negotiation: null and ID (links above) written up so far. Null: public data, info that everyone knows or can know (e.g., blog audit trail, new: can aggregate from multi sources for broader view). ID: who is asking? Policies around knowing "who is asking" include whitelist, known users, etc. for run-time determination of access. How to authenticate: soft or hard. Self-assertion by familiar party who is expected to come knocking soon, big company's signed assertion, etc. Add'l re claims handling: other statements (besides ID, e.g., age req'ment verifier), promises (if/then statements, potential references to Info Sharing Agreement), payment related info (receipts or promises).

Requester may be person, company, combination. Eve went thru car buying scenario for examples of process. Questions: how to direct host to release subset of info or filtered info (out of UMA scope but there's a workaround so it should be possible to do).

Car buying scenario: Sally = authorizing user, Dealership = requester, Insurance co = requester on behalf of Sally. Different roles: user, requesting user, authorized user (RFP). Two way communications in car buying scenario: dealer lets her know that something happened: permissioning requestor to gain access for purpose of putting info vs getting info.

Others in conversation w Eve: Drummond, Paul Trevithick, Phil Windley, Azigo.

Personal data store: relationship manager application, likely to represent authz mgr/policy decision point; may also represent one of person's hosts (e.g. flickr). Is handy to centralize (hosting self-asserting data): "it's not good unless you get it from (through) me." E.g. personal preferences are self-asserted data that the user is authoritative for.

Iain: we should look to standardize on same terminology. Joe: lexicon = shared power. "Host" is great term (info sharing has grand vision, UMA limited in scope). UMA is distinguishing between data store and host. Eve: we need a word for relationship manager (personal data store): AM of user's choice, 'host zero', possibly can serve as user requestor to others' data too (central recording and auditing). Iain: charter requires terms & defs. Joe: personal data store as a single service (rarely used); it's all the data in aggregate. (avoid honeypot) Eve: interesting use case; if this is successful in allowing apps to rely on data that lives somewhere but is useful elsewhere, flows thru an auth mgr (See Eve's blog entry on Identity Statelessness ).

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

NOTE: Do not follow the code with a "#" symbol as it may cause the code not to be recognized.