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

Davide Vaghetti davide.vaghetti at garr.it
Thu Jun 28 10:42:30 UTC 2018


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4136 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180628/7cd77cd5/attachment.p7s>


More information about the Openid-specs-ab mailing list