[Concordia] Notes from 10 Jan 2008 Concordia call

[Eve Maler]

I'll put these notes up on the wiki shortly.  Please let me know if  
you have corrections.

Attending:

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)


- Quick telecon time discussion

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.


- Quick ITU-T liaison discussion

Abbie Barbir has offered to be a liaison, and we are okay with that!   
We'd like to keep our liaison activities quite informal.


- Quick roundup of interested RSA interop participants

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


- Develop further detail on scenarios 1-2 and list any outstanding  
issues

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

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 (the "third interop scenario")

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.


- AI roundup:

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


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