Concordia telecon 10 Jan 2008
From Project Concordia
Contents |
Attendance
Scott Cantor (Shib), Ashish Jain (Ping), Mike Jones (Microsoft), Paul Madsen (NTT), Eve Maler (Sun), Sampo Kellomaki (Symlabs), Brett McDowell (LAP), Gaël Gourmelen (FT), George Fletcher (AOL), Jeff Hodges (Neustar), Uppili Srinivasan (Oracle)
Telecon time
The proposal is 1st and 3rd Tuesdays at 10-11am PT. We'll doublecheck on the list, but all participants on this call seem fine with it. We'll stick to the telecon number we used today; Brett says that's fine.
ITU-T liaison
Abbie Barbir has offered to be a liaison, and we are okay with that! We'd like to keep our liaison activities quite informal.
RSA interop participation
Everyone generally wants to see how the scenarios shake out and what system entity roles are involved before committing specifically to various flows, but all of the following confirmed active interest:
- Eve confirms for Sun
- Sampo confirms for Symlabs (participating in "all of the above" flows!)
- Mike confirms for MSFT (will participate with any WS-Fed and infocard parts, but they don't have a SAML kit today)
- Scott confirms for Shib (SP parts for sure; not sure about other roles)
- Ashish confirms for Ping
- Lena confirmed by email for FuGen
Scenarios 1-2 (Infocards + Federation)
Reference pages: RSA IOP Scenarios, Concordia telecon 13 Dec 2007
Paul notes that the email discussion in recent weeks went beyond what's on this page today. Scenario 2 is the one of most interest, in which authentication mechanisms play an interesting part. The question is how we choose to map such mechanisms into the infocard world. Current consensus seems to be that SAML will define five URIs: personal cards and the four permutations of managed cards. We still have to define four corresponding claim types to express the latter four, in order to make the cards light up. Mike confirms that it would be four claim types (vs. one claim with multiple values). This is because you can't articulate values in a policy, so for the sake of being able to match policies, you need distinct claims.
Regarding the request for authentication coming from a SAML SP, ultimately making its way to the STS: Mike confirms that MSFT has kernel code that a SAML token can come back from that. Scott notes that it's up to the STS what gets produced, no matter how the request comes in. Mike's product group wants to know from this community and the SAML community what example SAML tokens it would like to see coming from the MSFT code.
Do we want to see an authentication context or attribute statements/claim types? At IIW the conclusion seemed to be to reuse authn context for responses because we shouldn't be inventing something new. But because we have to use the claim type feature of the security policy framework, we need to be able to express the claim requests in attribute terms. So, effectively, we need to map onto both representations. (Paul observes that the GSA folks currently carry this sort of info in an attribute in responses.)
MSFT is planning to put up an STS endpoint that produces tokens of the SAML2 flavor. MSFT's WS-Fed implementation today supports SAML1.1 tokens and has internal code that supports SAML2 tokens.
Scenarios 1 and 2 are both "SP-initiated" in SAML terms, as we have captured them so far.
We think Boeing's basic scenario is a fine one to run with for now.
Scenario 11 aka "the third interop scenario" (WS-Fed + SAML2 chaining)
This is the one where WS-Fed and SAML integrate. Mike would like to see a description of how SAML expresses authentication contexts so he can discuss he implications with his WS-Fed team. Does this scenario amount to SAML2/WS-Fed chaining (which is semantically similar to SAML2/SAML1.1 chaining)? Hubert's previously blogged comparison matrix provides some basic info on this. If we constrain ourselves to whatever is currently implemented, that limits the scope of the work we'd have to do on this scenario.
Should we focus this scenario on IdP-initiated in order to spread around the different use cases a bit? Scott is against this, since he feels SP-initiated is more "real-world". WS-Fed and ADFS, according to Scott, support IdP-initiated flows. Eve and Paul are inclined to include IdP-initiated somehow for its usefulness in shaking out interop issues. Mike is disinclined because it may strain our resources. Let's ask deployers for more input.
How do people deal with chaining two technologies with differing features? The easy answer (already demoed at Catalyst a couple of years ago) is to use only an intersection of the features, but there's obviously little interop trouble there. More interesting is whether any deployers are "tunneling" features outside that intersection by using extension features of the more-capable technology. We'd like to survey people on this.
AIs
- Scott to put some example SAML tokens onto the wiki for Mike, leveraging Paul's list of claim types needed.
- Eve to ask Mike B. what specific SAML features they're using today and whether IdP-initiated flows are of interest.
- Eve to ask deployers for input on whether, in existing chaining scenarios, they "tunnel" features.
- (pending) Scott to flesh out the IdP discovery problem wiki page.
- Scott to update the scenario detail on the wiki and refactor the wiki a bit.
