<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 3/25/24 8:42 AM, Cantor, Scott via
users wrote:<br>
</div>
<blockquote type="cite"
cite="mid:6EA9535E-99DF-42BE-A3C7-2433EE0A2202@osu.edu">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">My intention in this discussion is not to be confrontational but to seek a shared
understanding of the SAML 2.0 specifications, especially regarding handling the
RelayState. According to the text from Errata E90:
</pre>
</blockquote>
</blockquote>
<p>I echo everything that Scott said. Without a signature over the
RelayState data, such as by a binding-level signature, the data is
subject to manipulation. So that's the main threat. That's why
sending non-opaque data like URLs or JSON is not wise.</p>
<p>But in terms of what I said earlier: Yes, in my rush to answer,
I did overlook the errata language which mentioned the possibility
of URLs "derived from" the RelayState. So obviously if the JSON
data contained literal URL(s) (e.g as a key value etc), then those
are subject to the requirements of the errata (RFC "MUST" and
"MUST NOT"). And technically, yes, if there is arbitrary data
there that later will be used in the
production/generation/derivation of URLs, then that would be
covered too, conceptually speaking. But note that, in the absence
of actual plainly visible URLs, no one but the SP could possibly
know how the data would be used for that purpose.</p>
<p>If you have questions or seek clarifications about the SAML spec
itself, there is an OASIS list (saml-dev) specifically for
questions like this:</p>
<p><a class="moz-txt-link-freetext" href="https://saml.xml.org/mail-lists-and-forums">https://saml.xml.org/mail-lists-and-forums</a><br>
</p>
<br>
</body>
</html>