<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
