[Concordia] Notes from 22 Jan 2008 Concordia telecon

[Eve Maler]

I'll post this on the wiki, and update other relevant bits, shortly.



== 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.

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 ? (Oracle), Abbie Barbir (Nortel)


== 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:

http://projectconcordia.org/index.php/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 ==

Our workshop slot at RSA is Monday 7 Apr 2008 9am-12:30pm, and we also  
have that room all day on Sunday for set up as well.)  Registration  
for our workshop is free of charge. To attend, register at http://www.rsaconference.com/2008/US/Registration.aspx 
  - click, 'register online now'.  Use the registration code 148CON.  
This will also give you a free expo pass that you can use to attend  
the tradeshow portion of the Conference Tuesday through Friday. YOU  
MUST BE REGISTERED THROUGH THE RSA CONFERENCE SITE TO ATTEND THIS  
WORKSHOP.  (This info is on our wiki.)

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:

http://projectconcordia.org/index.php/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.


Eve Maler                                         +1 425 947 4522
Principal Engineer                            eve.maler @ sun.com
Business Alliances group                    Sun Microsystems, Inc.