JSON dictionary in the Relay State parameter

[Cantor, Scott]

> And in that case, the IdP is supposed to send the RelayState back to the SP verbatim, if I
> understand Scott correctly. 

Not verbatim, because URL encoding isn't canonical. Multiple encoded strings can decode to the same value. As an example, both '+' and '%20' are used to denote spaces, but either is allowed. The string may be different at both steps because the encoding process is different, but the decoded value has to be the same in the end or somebody did it wrong.

> Before I head off to saml-dev about the OASIS spec, there seem to be three takes on the
>  matter.

There really aren't, and the errata doesn't enter into it. The errata has to do with SPs protecting themselves in their usage of the field, it has no bearing on the actual requirement on the IdP to be 100% faithful in returning the value.

> * You make a crucial point: only the SP knows how to use the RelayState, which can
> create a disconnect between how IdPs handle the data and the errata's broader security
> intentions. 

It does not, for the reason I stated. The spec requirements are clear and simple. The errata is about other stuff that doesn't enter into this conversation at all unless one is analyzing the SP's approach to relay state, which is not the IdP's problem.

It may be a *business* or *risk* problem to the buyer of some service, but honestly, this isn't even in the top 25 things that vendors get wrong with SAML or their applications, and ultimately the only exposure usually amounts to open redirect risks.

> Scott and your views start from a practical standpoint—emphasizing URL-encoding and
> the risks of unsigned data—while Oracle's broader approach aims at conceptual
> security, potentially covering scenarios beyond current standard practices or
> interpretations.

Oracle may or may not say that, but they'd be wrong as a matter of the standard. You don't get to "be helpful" to the SP, that's just not how it works.

-- Scott