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

["Philpott, Robert" <rphilpott@rsasecurity.com>]

My point (and Scott's, I think) is that the current wording in both B/A and
B/P could be interpreted to be underspecified since <ConfirmationMethod>
elements are not directly in an assertion; It is in a <SubjectConfirmation>
within a <SubjectStatement> within an <Assertion>.  Okay, the use of
lowercase "assertion" can be construed to mean everything within it, but
that kind of ambiguity leaves much to be desired.

I actually did consider your point when I proposed the change.  I just
wasn't absolutely sure that ALL assertions you sent in the <Response>'es of
the B/A or B/P profiles had to have ALL statements with the exact same
subject confirmation. So I limited it to just the SSO assertion.  I did
wonder if someone had a use case where they included other assertions in the
response [perhaps created earlier in time - not in the context of the SSO
profile] that were for the same subject, but that didn't have a confirmation
method.  If you're creating all of your assertions at the time of the SSO
profile exchange, sure, you can make sure to put artifact-01 or bearer in
all of the subject's confirmation methods.  But when the spec said "at least
one" of the assertions had to be an SSO assertion, it made me think maybe
they were pulled out of a cache from some earlier operation and you couldn't
put the confirmation method into them at that point.

I personally don't care for this type of scenario, but didn't want to
exclude the possibility, so, as I said, I just stuck to the SSO assertion. 

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 2:50 PM
> To: Philpott, Robert; ''Scott Cantor' '; Mishra, Prateek; '''Eve L. Maler'
> ' '; ''security-services@lists.oasis-open.org' '
> Subject: RE: [security-services] A browser/POST question...
> 
> <Rob>
> 
> PROPOSAL #1: I propose that we NOT make any statement about
> ConfirmationData
> change:
> -------------------
> The <saml:ConfirmationMethod> element of each assertion MUST be set to
> urn:oasis:names:tc:SAML:1.0:cm:bearer.
> -------------------
> to:
> -------------------
> The <saml:Subject> element for each statement being returned in the SSO
> assertion(s) MUST contain a <saml:SubjectConfirmation> element where the
> <saml:ConfirmationMethod> element MUST be set to
> urn:oasis:names:tc:SAML:1.0:cm:bearer.
> -------------------
> 
> </Rob>
> 
> 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".
> 
> Quoting from cs-sstc-bindings-01:
> 
> 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.
> 
> 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.
> 
> 
> 
> Now maybe this is a bad idea (Why? I dont yet see the problem). But I
> don't
> think we should address this in 1.1.
> 
> Therefore I would vote for alternative #2. There is really no substantive
> problem here and we do not have the cycles to work through this issue
> right
> now. Small changes to security protocols can have quite large
> consequences.
> 
> - prateek