RE: [security-services] FW: [saml-dev] Constrained delegation

["Scott Cantor" <cantor.2@osu.edu>]

> 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