[Federation] Treatment of metadata from superior entity

[Vladimir Dzhuvinov]

If iss and sub are not the same, then the entity statement MAY contain a metadata claim containing metadata asserted by a superior about the entity identified by sub.

https://openid.net/specs/openid-connect-federation-1_0.html#entity-statement

The current spec allows superiors (anchors and intermediates) to set metadata fields as well. If a field is set by a superior how is it applied to the subordinate metadata?

Eg if we assume the existing policy operators terminology : value or default?

https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.5.1.1

If a policy for the field is also present, which one of the two has precedence? Is the hierarchy in the trust chain also a factor here?

BTW, what was the reason to include this metadata feature in the spec? I couldn't find this change referenced in the doc history.

‌

‌

[Roland Hedberg]

This came about after I had a couple of discussions with potential users.

If a superior adds a metadata field it is basically a short hand for writing a metadata policy with value claims.

So instead of writing:

{
    "metadata_policy": {
        "openid_relying_party": {
            "policy_uri": {
                "value": "https://example.com/policy.html"            
            },
            "tos_uri": {
                "value": "https://example.com/tos.html"
            }
        }
    }
}

You could write

{
    "metadata": {
        "openid_relying_party": {
            "policy_uri": "https://example.com/policy.html",
            "tos_uri": "https://example.com/tos.html"        
        }
    }
}

The feeling among the group I talked to was that it where clearer and easier to read and manage policies if metadata could be used.

If an entity uses the metadata field as part of the policy expression then it MUST NOT use value in a metadata_policy expression in the same entity statement. All or none !

‌

[Giuseppe De Marco]

yes, this is a real issue
https://bitbucket.org/openid/connect/issues/1526/federation-treatment-of-metadata-from

in the current implementation I’ve worked on we normate the only usage of metadata_policy to avoid too many burocracy between leafs and fed entities and let the leafs have more liberties.

anyway I think that the metadata claim as it has been described in the current spec improves the flexibility of OIDC Fed. However, we need to put some words to normate how the metadata and the final_metadata built over the policy can cohexists together and with which precedence beetween them.

[Vladimir Dzhuvinov]

OK, Roland is essentially telling us that there are people who rather won't implement the policy language and just want to set fields in some straightforward ways at the intermediate or anchor level

So, my understanding now is that such metadata must be treated the same way as a “value” policy operator at the same level.

This will somewhat complicate the Connect2id library code and perhaps the code of others who aim to be completely compliant, but we can live with it

[Giuseppe De Marco]

So, “REQUIRED Conditional” means that only one of them can be present in a ES and not both of them, however we don’t have a normative language to say that metadata and metadata_policy CANNOT exists in the same statement

‌

[Torsten Lodderstedt]

This feature allows the superior to assert certain claims about the entity, e.g. the name of the entity or the identifier of the respective legal entity or its top level domain. This feature is essential to establish trust in such claims. The name, for example, might be shown in the user consent with the OP and should not be self asserted (in most cases).

[Vladimir Dzhuvinov]

With Torstens comment I see that this feature now has two uses:

1. To enable a superior to vouch for a particular metadata field of a leaf (which is not policy at all)
2. As shortcut for the “value” policy operator.

Should we document those explicitly in the spec?

[Roland Hedberg]

Yes, the code becomes more complicated but as you say we implementers can live with that.

Not sure what the difference is between asserting a claim and setting a value policy for that claim. But I agree there should be more descriptive text around this.

[Michael Jones]

@Roland Hedberg to write a PR.

[Giuseppe De Marco]

This PR touches this issues, thanks to @Roland Hedberg
https://bitbucket.org/openid/connect/pull-requests/208

[Michael Jones]

This will be fixed by https://bitbucket.org/openid/connect/pull-requests/208 .

[Giuseppe De Marco]

Closed by https://bitbucket.org/openid/connect/pull-requests/208