| Table of Contents | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Logistics
- Time: 08:00 PT | 11:00 ET | 16:00 UTC/GMT | 18:00 CEST (Time Chart)
- Skype: +9900827042954214
- US Dial-In: +1-201-793-9022
- Room Code: 295-4214
Agenda
1) Roll Call
...
Voting:
- Scott CantorKeith Uber
- RL "Bob" Morgan
- John Bradley
- Philippe ClementPaul Trevithick
Voting, but not present:
- Paul Trevithick
- Axel Nennker
- Keith Uber
- Philippe Clement
Non-voting:
- Trent AdamsBob Pinhero
- Benoit Bailleux
- Valeska O'Leary
Not present
- Gael Gourmelen
- Trent Adams
Quorate meeting (x 4 of y6)
2) Minutes
Approve Approved the following minutes:
3) Terminology
Three ISA architecturesWe discussed and agreed on the names for these three Identity Selector architectures:
- RP-embedded (like Managed Selector (e.g. our HTML mockup)
- Cloud selector (like Selector (e.g. Janrain, Avoco, Shiboleth Discovery etc.) --we formerly called this "ISA " by this ULX WG (and its predecessors)
- Active client selector
...
- in the network"
- Active Client Selector (e.g. a browser integrated application or an enhanced browser) --we formerly called this "ISA in the device"
Paul made some comments about recent discussions, e.g. at IIW, about Active Client Selectors:
- It is self-evident that the scope of ULX be limited to "next gen" active clients
- Some feel that "next gen" active clients to should rely on OAuth instead of using:
- Dedicated client UI to gather auth materials
- Dedicated UI to review/approve attribute/claim release
- WS-Trust to fetch (e.g. SAML) token
ISA Identity Selector Variations:
- User-aware vs. stateless --can we think of better names?
- Request-and-forward (ISA fetches token and POSTs to RP) vs. Selection-only -- can we think of better names?
4) Review ULX Scope (Creep)
- User <--> ISA UX
- ISA <--> RP (RP metadata)
- ISA <--> IdP (IdP metadata)
- NEW: ISA invocation for #2 and #3
5) ULX Sequence diagram
To discuss and correct from some points of view:
- Diagram tries to cover all three ISA architectures, does it succeed?
- It shows that ISA is directly fetching attributes and thus acting as an intermediary. Do we need another diagram variant that shows the architecture where the ISA makes the selection and does nothing else (aka "gets out of the way")
6) Proposal for an active client trigger:
- ulx://path-to-RP-metadata-JSON-for-HTTP
- ulxs//path-to-RP-metadata-JSON-for-HTTPS
7) ULX in HTTP request header
- Proposal: include ISA-related preference info in HTTP request header
- Info
- Most important: the user's choice of cloud selector URL
- Also: a set of user's preferred service providers (e.g. IdPs)
- How?
- Long term: Browsers could build this in
- Short term: a small browser extension could implement
- Why?
- Would provide a standard way for the user to exert their preference
8) Unresolved issues from previous meeting
- See http://kantarainitiative.org/confluence/display/ulx/ULX+Teleconference+2010-10-25 Walkthrough of Finnish selector use case (eg SP-driven IdP grouping and priorities) http://kantarainitiative.org/confluence/display/ulx/Use+Case+Finnish+services+for+citizens\configurable - the Identity Selector can be configured with the user's preferred set of IdPs and other preferences
4) ULX Scope
We discussed and agreed that the ULX WG scope includes working on the following kinds of interactions between an Identity Selector and:
- User
- User Experience
- Status: this is the first thing we worked on, we have an initial prototype
- Relying Party (1)
- Defining what metadata the RP must supply to the IS
- We have a JSON sample being circulated/discussed
- Relying Party (2) NEW
- Defining how a Cloud Selector and/or an Active Client Selector is invoked by the RP
- IdP
- Defining what metadata the IdP must supply to the IS
Scott: The "IdP Discovery Protocol" is not SAML dependent and could be used for the "Cloud Selector" case.
Next Meeting
- Time: 08:00 PT | 11:00 ET | 16:00 UTC/GMT (Time Chart)
- Skype: +9900827042954214
- US Dial-In: +1-201-793-9022
- Room Code: 295-4214