I would editorially tweak as follows (since it would be pretty unusual
for there to be real saml:SubjectStatement elements present):
Every subject-containing statement present in the assertion(s) returned
to the destination site MUST also contain a <SubjectConfirmation>
element. The <ConfirmationMethod> element in the <SubjectConfirmation>
MUST be set to urn:oasis:names:tc:SAML:1.0:cm:bearer.
Eve
Mishra, Prateek wrote:
> Scott, Rob:
>
> (1) Thanks for your paitence !
> (2) I finally understood the problem (that took a while!)
> (3) I have no problem with the following proposed text:
>
>
>
> Does this work? This one is for bearer, but we can update the
> artifact-01
> case similarly. It precludes the case I described in my last message,
> but I
> really am okay with the semantics described here...
> -------------------
> Every <saml:SubjectStatement> present in the assertion(s) returned to
> the
> destination site MUST contain a <saml:SubjectConfirmation> element. The
> <saml:ConfirmationMethod> element in the <saml:SubjectConfirmation> MUST
> be
> set to urn:oasis:names:tc:SAML:1.0:cm:bearer.
> -------------------
>
> 4) I agree this is kind of goofy overall and probably needs to be revised in
> SAML 2.0. For good or bad it was sort of the proposal in 1.0.
>
>
> - prateek
>
--
Eve Maler +1 781 442 3190
Sun Microsystems cell +1 781 354 9441
Web Technologies and Standards eve.maler @ sun.com
