[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Proposal on removing or clarifying use of Recipient attribute
Fulfilling action item from today's call: There are two optional attributes in core named "Recipient". One is in StatusResponseType, the other is in SubjectConfirmationDataType. The new one in <SubjectConfirmationData> is a functional replacement for the use of the old <Response> Recipient attribute in the SAML 1.1 POST profile, preventing a bearer assertion from being reused at the wrong relying party by an attacker. This attack is also mitigated by the use of <AudienceRestrictionCondition>, which indicates *who* can use the assertion; Recipient is used in the new SSO profile to also indicate *where* the assertion can be confirmed by the bearer. They are somewhat duplicative, but it was agreed on the call that this isn't a major problem. If people feel differently after reading a better explanation, that's fine too. It's mostly a historical thing. However, the original Recipient attribute in the protocol message remains in the schema, inherited from 1.1. It isn't normatively referenced anywhere at this point. It's purpose, if it were used, is essentially as before, to "target" a protocol message at a specific recipient or endpoint (it's probably reasonable to draw an analogy to the actor/role attribute in SOAP). It is currently unspecified whether this attribute could be used in the protocols we have defined, and it could be a source of interop problems if it's not clarified. I see two options: A) Remove the attribute, given that it's original purpose has been met with other message content. ID-FF protocols do not use such an attribute, and there are no related attacks against anything except the SSO protocol, which is already addressed. Therefore, one might conclude it isn't needed. B) Use the attribute, and add it to RequestAbstractType. Normatively specify within the HTTP front-channel bindings that the HTTP endpoints to which the SAML protocol messages are being sent MUST be placed in the attribute (though it can only be trusted if the message is signed, of course). Either option seems fine to me. I do think if we keep it that the bindings are the right place to specify the use of it. But I lean toward removal. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]