[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] FW: [saml-dev] Constrained delegation
> I accept that the SAML 2.0 assertion structure is flexible enough for > our purposes. I don't think anybody disputes the *ability* to communicate the semantic. Obviously not by accident, it's the reason we proposed that addition at the last minute. > But I don't see how a relying party can assume very much just based on > the presence or absence of NameId in an assertion. That is where the profile > fits in. But I've yet to hear anybody offer an alternative assumption. I started off writing that document based on the theory that even if I couldn't come up with one, somebody else probably could. I think it's time they did or we clarify the text and make life simple for ourselves. > This was also one reason I focused on the constraints on SAML > authorities and Relying parties in my example: > > http://lists.oasis-open.org/archives/security-services/200601/msg00046.html I don't think either one obligates the relying party. It communicates what the issuer is prepared to stand behind. I think the relying party has all sorts of potential policies it could choose to apply before it takes any action, including a deep dive into things like the strength of the algorithms used to apply the key proof. Also, I don't think us clarifying this semantic in core, or alternatively in the confirmation method definitions in profiles, precludes anybody from constructing an alternative interpretation using extensions. Defining the semantics of the elements in the schema doesn't prevent people from using the extension points to define different semantics. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]