[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]