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

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

> These are good points; maybe the issue is more about capturing or 
> recommending certain patterns of use vs. developing a new profile.

I think we should determine whether there are any other patterns of use.

If not, then what's missing is explicit language in core that is independent
of confirmation method that explains that the use of an identifier inside
the SC element explicitly means that the assertion issuer is granting that
entity the right to present the assertion as if it *were* the subject,
provided the accompanying requirements are met.

I believe the community at large would appreciate that clarification, and it
would greatly improve the ability for more complex scenarios to modeled
independently but interoperably.

So even if somebody were to come up with an alternative interpretation, I
would be inclined to reject it unless it was compelling.

> But before we discuss solutions, here is a question:-:
> 
> Is it important for SAML issuers and relying parties to 
> distinguish between:
> 
> (a) A system entity that presents a SAML assertion that 
> states "it" is named Joe; together with proof of possession..

> (b) A system entity that presents a SAML assertion, that states it is 
> named server X and is acting for Joe; together with proof of possession.

Clearly yes, but as Conor said, they can distinguish this. SAML 2 doesn't
require the use of an identifier in SC, it's optional. Without it, you get
the former.

-- Scott