And if I might tweak the tweak...
Change "subject-containing" to "subject-based"?
Rob Philpott
RSA Security Inc.
The Most Trusted Name in e-Security
Tel: 781-515-7115
Mobile: 617-510-0893
Fax: 781-515-7020
mailto:
> -----Original Message-----
> From: Eve L. Maler [mailto:]
> Sent: Thursday, May 01, 2003 6:50 PM
> To: '' ' '
> Subject: Re: [security-services] A browser/POST question...
>
> 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
