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

Jeff LOMBARDO jeff.lombardo at gmail.com
Thu Jul 26 13:52:48 UTC 2018


Hi Roland,

Thanks for the answer. Added to Davide ones, it gets clearer.

Regards

JF

Le jeu. 26 juil. 2018 04:02, Roland Hedberg <roland at catalogix.se> a écrit :

> 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"]}.*
>
>
> Correct!
>
> 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 <helpdesk at example.com>"]} *+ *ms_2{"contacts":
> ["rp_helpdesk at example.com <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 <rp_helpdesk at example.com>"]} *and not *sum(ms_0...2){"contacts":
> ["helpdesk at example.com <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 <helpdesk at example.com>", "rp_helpdesk at example.com
> <rp_helpdesk at example.com>"]}*.
>
>
> In fact, the attribute is labelled contact*S* so we expect many contacts
> here... but this is not possible cause even if I publish  *ms_2{"contacts":
> [ "helpdesk at example.com <helpdesk at example.com>", "rp_helpdesk at example.com
> <rp_helpdesk at example.com>"]}*, *"contacts": [ "helpdesk at example.com
> <helpdesk at example.com>", "rp_helpdesk at example.com
> <rp_helpdesk at example.com>"] *is not a subset of  *"contacts":
> ["rp_helpdesk at example.com <rp_helpdesk at example.com>"]* so not change can
> occur
>
>
> Correct!
>
> 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
> <rp_helpdesk at example.com>"]* is not a subset of  *["helpdesk at example.com
> <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/7a823e87/attachment.html>


More information about the Openid-specs-ab mailing list