[Concordia] Notes from 22 Jan 2008 Concordia telecon
Paul Madsen
paulmadsen at rogers.com
Wed Jan 23 09:54:20 EST 2008
based on yesterday's discussion, I've updated
http://projectconcordia.org/index.php/Infocard_Authentication_Scenario_Details
to address Mike's concerns about the IS invocation and policy expression
step
The Infocard RP now invokes the IS through the HTML <Object>, and
expresses the authentication mechanism requirements through a required
claim parameter within
For the different authn contexts, the Infocard RP builds a corresponding
Object
RequestedAuthnContext | Object syntax
-----------------------------------------------------------------------------------
personal | Issuer="self"
managed/pwd | RequiredClaims="managed/pwd"
managed/kerb | RequiredClaims="managed/kerb"
managed/X509 | RequiredClaims="managed/X509"
managed/personal | RequiredClaims="managed/personal"
Currently, the scenario has the SAML RP use the redirect binding to send
the AuthnRequest and the SAML IDP use the POST binding to send the
Response. Does this work for implementors?
Paul
p.s. 'SDAC' stood for 'Specifics, or Derived Assurance or
Characteristics' . For the IOP, we settled on the 'S', 'A' is next step. :-)
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.
>
> _______________________________________________
> Community mailing list
> Community at projectconcordia.org
> http://lists.projectconcordia.org/mailman/listinfo/community
>
> Participating in this discussion list does not grant any intellectual property rights or any commitment by the participants of the content discussed to any organization.
>
>
>
--
Paul Madsen e:paulmadsen @ ntt-at.com
NTT p:613-482-0432
m:613-282-8647
aim:PaulMdsn5
web:connectid.blogspot.com
More information about the Community
mailing list