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

[Jeff LOMBARDO]

Thanks Davide.

I see what you mean and I think I have to dive more into this compounded
metadata statement.

By the way I found a very small typo:

*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,*

*B(ms_C + SK[C) + A(ms_B + SK[B]))*

should be :

*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,*

*B(ms_C + SK[C]) + A(ms_B + SK[B]))*

Jeff

Le jeu. 28 juin 2018, à 06 h 48, Davide Vaghetti via Openid-specs-ab <
openid-specs-ab at lists.openid.net> a écrit :

> Hi Jeff,
>
> first time posting on this list for me as well, so you're in good
> company :-).
>
>
> On 27/06/2018 19:12, Jeff LOMBARDO via Openid-specs-ab 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>"]/}/
> > - 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 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 <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
> >
> > 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>"]./
> > /
>
> Well, yes an error will be thrown, but IMO it is the expected behavior.
> To me it does make sense that you can't enrich or change claims that has
> been accepted and signed by a superior authority. The rule is there to
> give you just one option, use a subset instead of the whole collection,
> everything else will throw an error.
>
> The subset rule for contacts may seem a little bit obscure, but it does
> make sense in cases where an RP has multiple contact emails and want to
> use a specific one for a certain OP. And that is allowed.
>
> In the case of tos_uri, policy_uri, logo_uri you won't allow an RP to
> declare a policy/tos/logo to the superior authority, and a different one
> to an OP. So, in this case the subset rule is really an equivalence one,
> in fact the subset for String claims is defined as "One string is a
> subset of another string if it is exactly the same, byte by byte."
>
> At least, this is my understanding of it, hope it helps.
>
> Cheers,
> Davide
>
> > /
> > Thanks for you feedback on that,
> >
> > Jeff
> >
> >
> >
> > _______________________________________________
> > Openid-specs-ab mailing list
> > Openid-specs-ab at lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-specs-ab
> >
>
> --
> Davide Vaghetti
> Consortium GARR
> Tel: +390502213158
> Mobile: +393357779542
> Skype: daserzw
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180703/8b4a683a/attachment.html>