<div dir="ltr">Thanks Davide.<div><br></div><div>I see what you mean and I think I have to dive more into this compounded metadata statement.</div><div><br></div><div>By the way I found a very small typo:</div><div>

<p id="gmail-rfc.section.3.4.1.p.3" style="margin-left:2em;margin-right:2em;color:rgb(0,0,0);font-family:verdana,helvetica,arial,sans-serif;font-size:13.3333px;text-decoration-style:initial;text-decoration-color:initial"><i>Creating a compounded metadata statements involves adding previously signed metadata statements to the request before signing it. So, if we start off with C sending this signing request to B,</i></p><pre style="margin-left:3em;background-color:lightyellow;padding:0.25em;color:rgb(0,0,0);font-size:13.3333px;text-decoration-style:initial;text-decoration-color:initial"><i>B(ms_C + SK[C) + A(ms_B + SK[B]))</i></pre>

should be :</div><div>

<p id="gmail-rfc.section.3.4.1.p.3" style="margin-left:2em;margin-right:2em;color:rgb(0,0,0);font-family:verdana,helvetica,arial,sans-serif;font-size:13.3333px;text-decoration-style:initial;text-decoration-color:initial"><i>Creating a compounded metadata statements involves adding previously signed metadata statements to the request before signing it. So, if we start off with C sending this signing request to B,</i></p><pre style="margin-left:3em;background-color:lightyellow;padding:0.25em;font-size:13.3333px;text-decoration-style:initial;text-decoration-color:initial"><i><font color="#000000">B(ms_C + SK[C</font><b style=""><font color="#ff0000">]</font></b><font color="#000000">) + A(ms_B + SK[B]))</font></i></pre>

Jeff</div></div><br><div class="gmail_quote"><div dir="ltr">Le jeu. 28 juin 2018, à 06 h 48, Davide Vaghetti via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Jeff,<br>
<br>
first time posting on this list for me as well, so you're in good<br>
company :-).<br>
<br>
<br>
On 27/06/2018 19:12, Jeff LOMBARDO via Openid-specs-ab wrote:<br>
> Hi,<br>
> <br>
> First post [ever on a RFC] so I hope I play by the rules. My apologies<br>
> if I don't.<br>
> <br>
> I have a problem understanding the multi metadata statement. Maybe it is<br>
> my core understanding of OIDC which is too raw.<br>
> <br>
> From the rule:  /Given two metadata statements ms_i and ms_j (j > i,<br>
> i=0, ..., n-1, j=1, ..., n) For every claim in ms_j: If the claim does<br>
> not appear in ms_i add it to ms_i. If the claim appears in ms_i then<br>
> replace the value of the claim in ms_i with the value of the claim in<br>
> ms_j if and only if the value in ms_j is a subset of the value in ms_i<br>
> else an error MUST be generated./<br>
> /<br>
> /<br>
> How can one hope to modify the Metadata statement? Along the rule, a<br>
> modification of metadata statement can only occur if the new statement<br>
> is a subset of the old one. The example is consistent with the rule and<br>
> may be acceptable for /"response_types"/ :/ms_1{"response_types":<br>
> ["code", "code id_token"]}/ + /ms_2{"response_types:<br>
> ["code"]}/ gives /sum(ms_0...2){"response_types: ["code"]}./<br>
> /<br>
> /<br>
> But I found the expected behavior strange<br>
> with /"contacts" /(and  /"logo_uri"/, /"policy_uri"/, /"tos_uri"/,<br>
> etc...). With /ms_0 {"contacts": ["<a href="mailto:helpdesk@example.com" target="_blank">helpdesk@example.com</a><br>
> <mailto:<a href="mailto:helpdesk@example.com" target="_blank">helpdesk@example.com</a>>"]} /+ /ms_2{"contacts":<br>
> ["<a href="mailto:rp_helpdesk@example.com" target="_blank">rp_helpdesk@example.com</a> <mailto:<a href="mailto:rp_helpdesk@example.com" target="_blank">rp_helpdesk@example.com</a>>"]//}/  one<br>
> may want to represent:<br>
> - a modification of /"contacts"/ in the latest metadata statement<br>
> bringing the result to /sum(ms_0...2){/"contacts":<br>
> ["<a href="mailto:rp_helpdesk@example.com" target="_blank">rp_helpdesk@example.com</a> <mailto:<a href="mailto:rp_helpdesk@example.com" target="_blank">rp_helpdesk@example.com</a>>"]/} /and<br>
> not /sum(ms_0...2){/"contacts": ["<a href="mailto:helpdesk@example.com" target="_blank">helpdesk@example.com</a><br>
> <mailto:<a href="mailto:helpdesk@example.com" target="_blank">helpdesk@example.com</a>>"]/}/<br>
> - an enrichment of /"contacts"/  bringing the result<br>
> to /sum(ms_0...2){/"contacts": [ /"<a href="mailto:helpdesk@example.com" target="_blank">helpdesk@example.com</a><br>
> <mailto:<a href="mailto:helpdesk@example.com" target="_blank">helpdesk@example.com</a>>"/, "<a href="mailto:rp_helpdesk@example.com" target="_blank">rp_helpdesk@example.com</a><br>
> <mailto:<a href="mailto:rp_helpdesk@example.com" target="_blank">rp_helpdesk@example.com</a>>"]/}/. In fact, the attribute is<br>
> labelled contact_S_ so we expect many contacts here... but this is not<br>
> possible cause even if I publish  /ms_2{/"contacts":<br>
> [ /"<a href="mailto:helpdesk@example.com" target="_blank">helpdesk@example.com</a> <mailto:<a href="mailto:helpdesk@example.com" target="_blank">helpdesk@example.com</a>>"/,<br>
> "<a href="mailto:rp_helpdesk@example.com" target="_blank">rp_helpdesk@example.com</a><br>
> <mailto:<a href="mailto:rp_helpdesk@example.com" target="_blank">rp_helpdesk@example.com</a>>"]/}/, /"contacts":<br>
> [ /"<a href="mailto:helpdesk@example.com" target="_blank">helpdesk@example.com</a> <mailto:<a href="mailto:helpdesk@example.com" target="_blank">helpdesk@example.com</a>>"/,<br>
> "<a href="mailto:rp_helpdesk@example.com" target="_blank">rp_helpdesk@example.com</a> <mailto:<a href="mailto:rp_helpdesk@example.com" target="_blank">rp_helpdesk@example.com</a>>"] /is not a<br>
> subset of  /"contacts": ["<a href="mailto:rp_helpdesk@example.com" target="_blank">rp_helpdesk@example.com</a><br>
> <mailto:<a href="mailto:rp_helpdesk@example.com" target="_blank">rp_helpdesk@example.com</a>>"]/ so not change can occur<br>
> <br>
> In all cases, the result is not consistent with the rule as  /an error<br>
> should have been generated /cause /[//"<a href="mailto:rp_helpdesk@example.com" target="_blank">rp_helpdesk@example.com</a><br>
> <mailto:<a href="mailto:rp_helpdesk@example.com" target="_blank">rp_helpdesk@example.com</a>>"]/ is not a subset<br>
> of  /["<a href="mailto:helpdesk@example.com" target="_blank">helpdesk@example.com</a> <mailto:<a href="mailto:helpdesk@example.com" target="_blank">helpdesk@example.com</a>>"]./<br>
> /<br>
<br>
Well, yes an error will be thrown, but IMO it is the expected behavior.<br>
To me it does make sense that you can't enrich or change claims that has<br>
been accepted and signed by a superior authority. The rule is there to<br>
give you just one option, use a subset instead of the whole collection,<br>
everything else will throw an error.<br>
<br>
The subset rule for contacts may seem a little bit obscure, but it does<br>
make sense in cases where an RP has multiple contact emails and want to<br>
use a specific one for a certain OP. And that is allowed.<br>
<br>
In the case of tos_uri, policy_uri, logo_uri you won't allow an RP to<br>
declare a policy/tos/logo to the superior authority, and a different one<br>
to an OP. So, in this case the subset rule is really an equivalence one,<br>
in fact the subset for String claims is defined as "One string is a<br>
subset of another string if it is exactly the same, byte by byte."<br>
<br>
At least, this is my understanding of it, hope it helps.<br>
<br>
Cheers,<br>
Davide<br>
<br>
> /<br>
> Thanks for you feedback on that,<br>
> <br>
> Jeff<br>
> <br>
> <br>
> <br>
> _______________________________________________<br>
> Openid-specs-ab mailing list<br>
> <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
> <br>
<br>
-- <br>
Davide Vaghetti<br>
Consortium GARR<br>
Tel: +390502213158<br>
Mobile: +393357779542<br>
Skype: daserzw<br>
<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>