Concordia telecon 22 Jan 2008
From Project Concordia
Contents |
Next meeting
We meet again on Tuesday, 5 Feb 2008, at 10-11am PT etc., at the same number. The wiki home page always has the latest call detail. Paul will run that call (Eve will be catching a plane at that hour). We'll continue to discuss scenario details by email in the meantime.
AI summary
New from this meeting:
- Eve to work up a draft of presentation material, and Mike (at least) to review and comment.
- All to collate A/V needs for RSA by the end of February.
- All to register for the workshop at RSA if they're planning to attend.
Pending:
- Scott to flesh out the IdP discovery problem wiki page.
Attendance
Eve Maler (Sun), Paul Madsen (NTT), Mike Jones (Microsoft), Brett McDowell (Liberty), Jeff Broberg (CA), Eric Tiffany (Liberty), Charles Andres (Parity), Drummond Reed (Cordance), Jeff Hodges (Neustar), John Kemp (Nokia), George Fletcher (AOL), Collin Wallis (NZ), Bill Young (NZ), Uppili Srinivasan (Oracle), Abbie Barbir (Nortel), Sampo Kellomäki (Symlabs)
AI review
AIs from last time:
- Scott to put some example SAML tokens onto the wiki for Mike, leveraging Paul's list of claim types needed.
Paul and Scott have largely done this, and Scott will add further detail to complete the AI. The details page is at Infocard Authentication Scenario Details.
- Eve to ask Mike B. what specific SAML features they're using today and whether IdP-initiated flows are of interest. (DONE; Mike responded on the list)
We took the opportunity on the call to ask Bill Young what NZ uses. They have only SP-initiated at the moment, with IdP-initiated flows at least a year out. IdP discovery is easy because they have exactly one IdP, so it's classic pre-configured hub/spoke. Also, NZ uses SAML exclusively, so it doesn't have any feature-tunneling issues into WS-Fed. This may come up in future.
- Eve to ask deployers for input on whether, in existing chaining scenarios, they "tunnel" features. (DONE, belatedly)
No feedback from others yet, besides Mike Beach and Bill Young.
- (pending) Scott to flesh out the IdP discovery problem wiki page.
Still pending. Bill Y. might be able to contribute thoughts in a few weeks' time.
- Scott to update the scenario detail on the wiki and refactor the wiki a bit.
This was done by Paul; the two scenarios now have separate pages (but the SAML/WS-Fed scenario page is still a stub).
- Another old AI: Brett has reached out to Liberty Interoperable technology providers to see if any of them want to participate in the interop. This is closed.
Interop participants
Oracle may participate in the interop; Uppili will report back. CA will consider taking part as well.
Britta needs to know our room needs (e.g. A/V equipment) by end of February.
RSA event participation
If you intend to be at the RSA Concordia interop, you must register (it's free and entitles you to visit the expo too). Go to the RSA registration site click register online now. Use the registration code 148CON.
Apparently 105 people have already registered for our workshop! And that probably doesn't include a lot of us on this call, who may have missed seeing this info till now. We suspect it's not possible to reach out to all these people by email ahead of time (given RSA's rules about sharing contact info). The next best thing is to make clear what we intend to do right at 9am on Monday, and try to effectively engage the small percentage of attendees who have deployment input to offer. Would it be possible to do a "staged" presentation/demo for the first segment, and then invite attendees to visit pods?
Mike's experience with the OSIS interops was that there was plenty of time for attendees to visit pods and talk to developers. But they did seem to miss an opportunity to educate people coming in from outside on what we're doing and why this matters. 60 or 90 minutes at the beginning would be useful, along with a Q&A of attending deployers about (a) their deployment issues with the scenarios we're testing and (b) their other most important deployment issues.
Infocard/federation scenario review
Bill noted that NZ has a lab project about to launch that will involve CardSpace.
Paul had invented the four-letter acronym "SDAC"; we can't remember what it stands for but it means the collection of specific authn context + level of assurance info (not caring which one). Other terminology: Let's stick to SP for SAML relying parties and RP for infocard relying parties.
We walked through the new scenario page: Infocard Authentication Scenario Details.
Mike thinks the "SAML IDP/Infocard RP invokes Selector" flow item needs fixing. For starters, it's asking for a token type of SAML2 for a self-issued card; we know of no selectors that issue SAML2 tokens for self-issued cards, and self-issued cards can't add arbitrary claims. Paul's thinking is that there needn't be any required claim in this case -- it can return the appropriate SAML2 authn context in a pre-configured fashion. But this will probably have to be a SAML1.1 assertion that it needs to convert into SAML2. The assumption we need to hold, in general, is that whatever comes back from the selector will have to be converted in some fashion.
Also, the SAML IdP/Infocard RP needs to take the policy coming from the SAML SP and dynamically construct a selector interaction that will try to satisfy the SP's request. Is there redundancy in this step? Mikes asks if the "RP/STS role" (as infocard folks call it) is necessary here. HTTP POST could be used here instead of WS-Trust. We use the "required claims" trick (using SAML attributes containing specially interpreted URIs to communicate desired the authn context back to the infocard IdP piece) here.
Regarding how to express which (infocard RP) IdP issued the card, do we need to name a specific provider (less flexible)? It's more powerful to demonstrate card-matching based on authn context matching than hard-coding an issuer.
Jeff notes that there was a recent http://blogs.msdn.com/card/ blog entry that may be relevant to our solution here. Mike thinks that the approach in that entry isn't necessary to apply here; it's redundant.
