[Concordia] Notes from 1 Apr 2008 Concordia call

[Ari Kermaier]

I'm not sure that needing to configure the heirarchy on the SP and/or the IdP is a usability deal-breaker. The acceptable authn mechanisms, and their ordering, is not typically so ad hoc within a given federation, nor is it likely to be in constant flux. Agreement among providers in a CoT would allow for configuration to cover the various scenarios, I think.

::Ari


> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2 at osu.edu]
> Sent: Wednesday, April 02, 2008 3:55 PM
> To: ari.kermaier at oracle.com; 'Paul Madsen'
> Cc: 'Concordia Community list'
> Subject: RE: [Concordia] Notes from 1 Apr 2008 Concordia call
> 
> 
> > 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.
> 
> I maintain session state, but I don't maintain this contextual state.
> Furthermore, it wouldn't help. An unsolicited response from 
> the IdP would
> carry a specific context class or declaration, and then 
> you're back in the
> same boat, with the SP or app having to be touched every time 
> something is
> changed wrt to the hierarchy in order to know what would be 
> acceptable.
> 
> So even if I felt it was right to make the IdP the PEP for 
> this, and I'm
> not, it isn't sufficient.
> 
> The reason I'm on the fence somewhat is that no matter what 
> you do, either
> the SP or IdP has to be touched, and I'm not always convinced 
> that it's
> better to push every single problem on the IdP. But usually that's the
> default position most people take.
> 
> -- Scott
> 
> 
>