<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
OK, thank you.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
I agree with Scott also. He assumes, correctly (I checked to make sure) that the SP sends a URL-encoded RelayState, in this case, a URL-encoded JSON dictionary. Here it is, URL-encoded (with some data values changed):</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
RelayState=%7B%22action%22%3A%22login%22%2C%22accountId%22%3A%0123456789-7cd3-46ff-a6f4-012345678912%22%2C%22redirect%22%3Anull%7D</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
And in that case, the IdP is supposed to send the RelayState back to the SP verbatim, if I understand Scott correctly. </div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
That's not what Oracle Access Manager 12c does. URL-decodes the RelayState, replaces the curly braces and quotation marks with a Unicode character, and sends that instead. The Oracle IdP behavior seems to rely on an expansive interpretation of E90, at 4.1.6,
as you note below.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">Then again, as Scott says, "...</span><span style="font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif; font-size: 14.6667px; color: rgb(36, 36, 36); background-color: rgb(255, 255, 255);">your
Oracle IdP is, huge shock, broken. That will not be the only bug, trust me.</span><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">" For the record, I trust Scott.
Shibboleth did not have this issue.</span></div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Before I head off to saml-dev about the OASIS spec, there seem to be three takes on the matter.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<p class="elementToProof" style="margin-top: 0px; margin-bottom: 0px;"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(14, 16, 26);">With your correction, the gap between
the interpretations narrows slightly, particularly with his acknowledgment that data used to derive URLs, not just explicit URLs, falls under the errata's guidance. However, inconsistencies remain:</span></p>
<ul style="margin-top: 0pt; margin-bottom: 0pt;">
<li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(14, 16, 26); margin-top: 0pt; margin-bottom: 0pt; list-style-type: disc;">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(14, 16, 26);">
While Scott focuses on the procedural integrity of data transmission, you and Oracle recognize broader risks associated with the data's content and its potential use. The inconsistency lies in how different parties interpret and address these risks broadly
or narrowly.</div>
</li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(14, 16, 26); margin-top: 0pt; margin-bottom: 0pt; list-style-type: disc;">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(14, 16, 26);">
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. </div>
</li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(14, 16, 26); margin-top: 0pt; margin-bottom: 0pt; list-style-type: disc;">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(14, 16, 26);">
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.</div>
</li></ul>
<div class="elementToProof" style="margin-top: 0pt; margin-bottom: 0pt; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif; font-size: 14.6667px; color: rgb(36, 36, 36);">
<span style="background-color: rgb(255, 255, 255);">Many thanks,</span></div>
<div class="elementToProof" style="font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif; font-size: 14.6667px; color: rgb(36, 36, 36);">
<span style="background-color: rgb(255, 255, 255);">Florian</span></div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<hr style="display: inline-block; width: 98%;">
<div style="direction: ltr; font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<b>From:</b> users <users-bounces@shibboleth.net> on behalf of Brent Putman via users <users@shibboleth.net><br>
<b>Sent:</b> Monday, March 25, 2024 2:28 PM<br>
<b>To:</b> Shib Users <users@shibboleth.net><br>
<b>Cc:</b> Brent Putman <putmanb@georgetown.edu><br>
<b>Subject:</b> Re: JSON dictionary in the Relay State parameter</div>
<div style="direction: ltr;"> </div>
<div style="background-color: rgb(255, 252, 213); margin: 2em; border-width: 1px; border-style: solid; border-color: initial;">
<p style="text-align: center; padding: 1em;"><b>* This email originates from a sender outside of CUNY. Verify the sender before replying or clicking on links and attachments. *</b></p>
</div>
<p><br>
</p>
<div class="elementToProof">On 3/25/24 8:42 AM, Cantor, Scott via users wrote:</div>
<blockquote>
<blockquote>
<pre><div>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:
</div></pre>
</blockquote>
</blockquote>
<p class="elementToProof">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 class="elementToProof">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 href="https://urldefense.com/v3/__https://saml.xml.org/mail-lists-and-forums__;!!PxiZbSOawA!Nx7EUHj_Stm4KXb5JCmbrdFmeKVCVZRhoJtfG6xvISRBjB0SN6GZjpPWMW14fAWwSNLy__e9C1JBUoEyWSB8ilx8$" id="OWA744027f4-be92-95d1-a3d2-1afee6a57ccc" class="x_moz-txt-link-freetext OWAAutoLink" shash="BqZnHLTnWW+gdZgUzXaENuqI1Y3tCys7ikO+Ae13HHThQPTHBvWPPnPqvrrSgTVHLggjRuoJxHVxyF8UtcvpwGuUSAW1USEiw14iRJZxRXYdVbPtqlt6wYu/usBJ50cJyW+H8NneSe5oJmcygfczsEteMVeklBwG6PsbQNXDLB0=" originalsrc="https://urldefense.com/v3/__https://saml.xml.org/mail-lists-and-forums__;!!PxiZbSOawA!Nx7EUHj_Stm4KXb5JCmbrdFmeKVCVZRhoJtfG6xvISRBjB0SN6GZjpPWMW14fAWwSNLy__e9C1JBUoEyWSB8ilx8$" data-auth="Verified" data-loopstyle="linkonly" style="margin-top: 0px; margin-bottom: 0px;">https://saml.xml.org/mail-lists-and-forums</a></p>
<br>
</body>
</html>