[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Suggested text for replacement/enhancement of Recipient attribute
The consensus (ok, maybe a bit strong) on the focus call was to go ahead and lock down the front-channel bindings with a properly defined Recipient attribute on the protocol envelopes. Note: I'm not talking about the SubjectConfirmationData attribute. Different thing, though similar. I propose we rename this to something else. I suggest "Destination", which more strongly connotes "address" as opposed to "identity". I reviewed WS-Addressing, and the best choices to me were "Destination", "Address" or "To" and Destination seemed the most clear. Changes to core: Add to section 3.2.1, RequestAbstractType definition: <<< Destination [Optional] A URI reference indicating the address to which this request has been sent. This is useful to prevent malicious forwarding of requests to unintended recipients, a protection that is required by some protocol bindings. If it is present, the actual recipient MUST check that the URI reference identifies the location at which the message was received. If it does not, the request MUST be discarded. Some protocol bindings may require the use of this attribute (see [SAMLBind]). >>> In section 3.2.2 (currently it's mis-numbered as 3.2.1.1), StatusResponseType definition, remove the Recipient attribute, and replace with: <<< Destination [Optional] A URI reference indicating the address to which this response has been sent. This is useful to prevent malicious forwarding of responses to unintended recipients, a protection that is required by some protocol bindings. If it is present, the actual recipient MUST check that the URI reference identifies the location at which the message was received. If it does not, the response MUST be discarded. Some protocol bindings may require the use of this attribute (see [SAMLBind]). >>> Changes to bindings: Add text to the Security Considerations sections of the Redirect and POST bindings, sections 3.4.5.2 and 3.5.5.2: <<< If the message is signed, the Destination XML attribute in the root SAML element of the protocol message MUST contain the URL to which the sender has instructed the user agent to deliver the message. The recipient MUST then verify that the value matches the location at which the message has been received. >>> I will subsequently update the examples in the document as well. I don't believe we have to say anything in profiles, per the layering in the spec. Various profiles require signing when using POST or Redirect, and signing thus implies use of the attribute as above across all of them. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]