[Concordia] Notes from 22 Jan 2008 Concordia telecon

Tue Jan 22 14:49:01 EST 2008

Now posted:

http://projectconcordia.org/index.php/Concordia_telecon_22_Jan_2008

I apologize for not having filled in Uppili's full name before sending  
the notes in email!  I wanted to make sure to spell it correctly, but  
forgot to get to that...  If anyone has corrections, feel free to edit  
the wiki page to reflect them.

In the online version, I added another action item for everyone to  
register for the workshop at RSA if you're planning to attend.  There  
are very good instructions on the main page of the wiki and also in  
today's meeting notes for how to do this.  Please take care of this  
before you forget!

	Eve

On Jan 22, 2008, at 11:21 AM, Eve Maler wrote:

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