[Openid-specs-ab] OpenID Federation: Multi Metadata statement example questions

Roland Hedberg roland at catalogix.se
Thu Jul 26 08:01:54 UTC 2018

Hi Jeff,

sorry about the late response but I’m on vacation so I don’t read my emails as often as I normally do.

> On 20 Jun 2018, at 21:25, Jeff LOMBARDO via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> Hi,
> First post [ever on a RFC] so I hope I play by the rules. My apologies if I don’t.


> I have a problem understanding the multi metadata statement. Maybe it is my core understanding of OIDC which is too raw.
> From the rule:  Given two metadata statements ms_i and ms_j (j > i, i=0, ..., n-1, j=1, ..., n) For every claim in ms_j: If the claim does not appear in ms_i add it to ms_i. If the claim appears in ms_i then replace the value of the claim in ms_i with the value of the claim in ms_j if and only if the value in ms_j is a subset of the value in ms_i else an error MUST be generated.
> How can one hope to modify the Metadata statement? Along the rule, a modification of metadata statement can only occur if the new statement is a subset of the old one. The example is consistent with the rule and may be acceptable for "response_types" : ms_1{"response_types": ["code", "code id_token"]} + ms_2{"response_types: ["code"]} gives sum(ms_0...2){"response_types: ["code"]}.


> But I found the expected behavior strange with "contacts" (and  "logo_uri", "policy_uri", "tos_uri", etc...). With ms_0 {"contacts": ["helpdesk at example.com <mailto:helpdesk at example.com>"]} + ms_2{"contacts": ["rp_helpdesk at example.com <mailto:rp_helpdesk at example.com>"]}  one may want to represent:

> - a modification of "contacts" in the latest metadata statement bringing the result to sum(ms_0...2){"contacts": ["rp_helpdesk at example.com <mailto:rp_helpdesk at example.com>"]} and not sum(ms_0...2){"contacts": ["helpdesk at example.com <mailto:helpdesk at example.com>”]}

As you state below neither is correct.

> - an enrichment of "contacts"  bringing the result to sum(ms_0...2){"contacts": [ "helpdesk at example.com <mailto:helpdesk at example.com>", "rp_helpdesk at example.com <mailto:rp_helpdesk at example.com>"]}.

> In fact, the attribute is labelled contactS so we expect many contacts here... but this is not possible cause even if I publish  ms_2{"contacts": [ "helpdesk at example.com <mailto:helpdesk at example.com>", "rp_helpdesk at example.com <mailto:rp_helpdesk at example.com>"]}, "contacts": [ "helpdesk at example.com <mailto:helpdesk at example.com>", "rp_helpdesk at example.com <mailto:rp_helpdesk at example.com>"] is not a subset of  "contacts": ["rp_helpdesk at example.com <mailto:rp_helpdesk at example.com>"] so not change can occur


So, it’s ms_0 that has to list all the possible values used in ms_i (i > 0) or not list any values.

> In all cases, the result is not consistent with the rule as  an error should have been generated cause ["rp_helpdesk at example.com <mailto:rp_helpdesk at example.com>"] is not a subset of  ["helpdesk at example.com <mailto:helpdesk at example.com>"].
> Thanks for you feedback on that,

The reasoning behind the rule is that someone high up in the chain can restrict what someone lower down can use.
Or it can refrain from making any restrictions. Which means it won’t set any value for a specific claim.

So, using your example if we have ms_0 {‘contacts’ : [‘helpdesk at example.com’]} then the only values allowed for ms_i (i>0) to use is  [‘helpdesk at example.com’]

If on the other hand we have ms_0 {‘contacts’ : [‘helpdesk at example.com’, ‘rp_helpdesk at example.com’]} then ms_i (i>0) can use one of
 [‘helpdesk at example.com’, ‘rp_helpdesk at example.com’],  [‘helpdesk at example.com’]  or [‘rp_helpdesk at example.com’]

Someone lower down in the chain can never extend a claim set by someone higher up.

OK ?

— Roland

The higher up you go, the more mistakes you are allowed. Right at the top, if you make enough of them, it's considered to be your style. 
-Fred Astaire, dancer, actor, singer, musician, and choreographer (10 May 1899-1987)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180726/e286933d/attachment.html>

More information about the Openid-specs-ab mailing list