OpenSAML user discussion

["Scott Cantor" <>]

> There is no challenge-response pattern here, this attribute is really
> just meant for message correlation. So the entity can literally say "Ah,
> this message is in response to the message X, that I sent."  Or, put
> another way, it's a bit of state for tracking request/response pairs.

Correlation itself is a security feature, but it's much more critical for
synchronous messaging than asynchronous unless you need it for state, and
that's less about security.

> It's probably also important to note that this attribute need not even
> be present in all response messages (e.g. unsolicited authentication
> response).

It is required with the SOAP binding, for example, but otherwise no.

> Now, as Scott said, you can implement some sanity checks that looks for
>  entity A sending entity B a message and specifying an in-response-to
> message ID that entity B didn't issue.  This probably raises a flag but
> honestly it may not.

It definitely is something the SOAP client checks, and if I hadn't botched
that check way back years ago, I'd have avoided an ugly security bug caused
by libcurl buffering responses. But for front-channel, I haven't run into
any use cases for it yet that RelayState alone wouldn't meet anyway. In
essence that's what it is, just constrained to an XML ID syntax, and you get
the advantage that it's inside the message and signed with it.

-- Scott