OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [security-services] A browser/POST question...


Dueling responses going on - I can't keep up :-)

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.
-------------------

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:rphilpott@rsasecurity.com 


> -----Original Message-----
> From: Mishra, Prateek [mailto:pmishra@netegrity.com]
> Sent: Thursday, May 01, 2003 3:10 PM
> To: 'Scott Cantor '; Mishra, Prateek; Philpott, Robert; ''''Eve L. Maler'
> ' ' '; 'security-services@lists.oasis-open.org '
> Subject: RE: [security-services] A browser/POST question...
> 
> Agreed, there is some confusion here concerning the repeated occurrence of
> SubjectStatement. This is not clearly described: instead assertions are
> described as holding ConfirmationMethods in the text. Sigh ! This is a
> consequence of the relatively late "generalization" in SAML 1.0 wherein
> assertions could hold multiple statements (and each statement carries
> <ConfirmationMethod> and other stuff!).
> 
> OK, so the proposed clarification would be replace:
> 1)
> 
> Section 4.1.1.6
> 
> The <saml:ConfirmationMethod> element of each assertion MUST be set to
> urn:oasis:names:tc:SAML:1.0:cm:artifact-01.
> 
> BY
> 
> The <saml:ConfirmationMethod> element of each statement in each assertion
> MUST be set to urn:oasis:names:tc:SAML:1.0:cm:artifact-01
> 
> 
> 2)
> 
> Section 4.1.2.5
> 
> The <saml:ConfirmationMethod> element of each assertion MUST be set to
> urn:oasis:names:tc:SAML:1.0:cm:bearer.
> 
> BY
> 
> The <saml:ConfirmationMethod> element of each statement in each assertion
> MUST be set to urn:oasis:names:tc:SAML:1.0:cm:bearer.
> 
> 
> 
> - prateek
> 
> c: 781-308-5198
> 
> -----Original Message-----
> From: Scott Cantor
> To: 'Mishra, Prateek'; 'Philpott, Robert '; '''Eve L. Maler' ' ';
> security-services@lists.oasis-open.org
> Sent: 5/1/2003 2:57 PM
> Subject: RE: [security-services] A browser/POST question...
> 
> > My problem is that this is a change in semantics. Instead of
> > ALL assertions being transferred as "bearer" assertions only
> > the SSO assertions now have these properties.
> >
> > Both the artifact and FORM/Post profile permit multiple
> > assertions to be transferred. In each case, the
> > <ConfirmationMethod> is to be set appropriately either to
> > "artifact" or to "bearer".
> 
> If that's true (and it does match what the text says), then we should at
> least edit the text to properly clarify that *every*
> SubjectStatement (or derived element thereof) is to include that method.
> 
> Saying "the assertion contains" is something that shows up all over and
> just creates confusion in the same way that having multiple
> assertions in responses can create confusion if the language just
> implies one.
> 
> -- Scott


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]