[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Stateless Conformity To SAML
> I think it would be a bad idea to define "SAML conformant" to > *only* cover the ID-FF use cases; there must be some way for > a product that supports other use cases, such as > attribute-based federation, to be conformant. > > One possibility would be to have "conformance targets" that > correspond to the existing SAML browser profiles/bindings, > without the extra account linking features that came in with SAML 2.0 As I've said before, I disagree with the contention that "account linking" is a new feature of 2.0. What is new is having a specific "persistent" NameID format designed for privacy preservation, which wasn't precluded in 1.1 but wasn't standardized. And of course, having a protocol for informing a relying party that a NameID has changed. However, attribute-based linking aside, all of the existing NameID formats in 1.1 supported account linking. This isn't new. Maybe it's a new way of thinking for people that they just didn't see before. So statefulness is also not new. A question is how explicit to make the notion of persistence of user identity in the SSO use case given that there are potential conformance implications now for supporting a profile that assumes persistence, since the profile is worthless without it. One obvious option is to make the mgmt profile optional in light of the fact that not everybody is apparently planning to implement support for it anyway. The advantage to establishing a distinct conformance class for "non-persistent" IdPs/SPs would be to call out *why* it's optional, and insure that it's MTI if you're supporting the persistent use cases, which is how I read Greg's suggestion. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]