[Concordia] Notes from 1 Apr 2008 Concordia call

[Ari Kermaier]

I guess I'm coming from a different perspective: I'm assuming SAML 2.0 for this sort of functionality, and my implementation both maintains session state at the SP and provides configuration to create orderings of authn mechanisms for purposes of RequestedAuthnContext Comparison usage.

::Ari

> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2 at osu.edu]
> Sent: Wednesday, April 02, 2008 12:14 PM
> To: ari.kermaier at oracle.com; 'Paul Madsen'
> Cc: 'Concordia Community list'
> Subject: RE: [Concordia] Notes from 1 Apr 2008 Concordia call
> 
> 
> > Why can't the Comparison attribute of the 
> RequestedAuthnContext be used in
> > these cases, e.g.
> >
> > 	<samlp:RequestedAuthnContext Comparison="minimum">
> >
> >
> <saml:AuthnContextClassRef>urn:...:incommon:bronze</saml:AuthnContext
> > ClassRef>
> > 	</samlp:RequestedAuthnContext>
> >
> > This works for LoA and similar systems as well, since these 
> are typcally
> an
> > ordered list based on "strength".
> 
> Well, first, you're assuming SAML 2.0 here. Our federation is 
> currently SAML
> 1.1-based. Our software also doesn't yet implement comparison 
> other than
> equality at the IdP, because it's not clear to us that it's 
> workable for
> deployers to configure. Our IdP is hard enough to configure already.
> 
> The other (main) problem is that unless you just trust the 
> IdP to do the
> right thing, and maintain enough state at the SP, the SP or 
> application
> still has to verify that the context is acceptable to it. In 
> other words, I
> think the purpose of requesting it is to prevent needless 
> denial of access,
> not to make the IdP the enforcement point. My SP doesn't even tie the
> response to the original request. I didn't think the payoff 
> was worth the
> work of preserving the state in a manner that would be tamper-proof in
> typical deployments.
> 
> All just MHO.
> 
> -- Scott
> 
> 
>