Duplicated metadata parameter organization_name

[Stefan Santesson]

organization_name is defined both in 4.1 and in 4.2.6 for the Federation entity.

The definition in 4.2.6 is redundant as the definition in 4.1. can be used by all entity types.

[Stefan Santesson]

I don’t want to open another issue for this, but now when we discuss metadata parameters, I have some additional thoughts.

First, I think it would make sense to move logo_uri to 4.1 from 4.2.6 and make it available for all entity types as OPTIONAL parameter.

Client metadata already has logo_uri as an OPTIONAL parameter for display to the user at the OP. I think it is equally relevant in an open federation that the RP can show the logo of the OP when the user selects ID provider.

I understand that this didn’t make sense when you manually added each OP to the RP. But with OpenID federation, a whole pile of OP:s can now be directly available for every RP. So now I think it makes sense.

‌

Ideally I would also like to have access to a display_name, but I can't figure out a good way. Client metadata already has client_name for this purpose and adding another parameter for the same purpose for clients could therefore be problematic. Having different parameter for different entity types is less nice. So I guess organization_name will have to do. But a real organization name may not be ideal as you may want to display the name of the service rather than the organization name.

E.g. The most common eID provider in Sweden has a service called BankID. However the organization name is “Finnansiell ID teknik”. Showing the organisation name in this case makes no sense.

I would highly appreciate your thoughts on this as well.

[Michael Jones]

Hi Stefan. Good catches! I noticed some of the same things in my recent review of the spec.

organization_name is now defined only once - in the new section https://openid.net/specs/openid-federation-1_0-31.html#name-informational-metadata-exte . The other metadata parameters that are potentially universally applicable are also there.

Let us know if you agree that the changes in -31 resolve this issue, or if not, what else you believe needs to be done. Thanks!

[Stefan Santesson]

Ohh. I was looking at draft 30. Didn’t notice the update. And you did what I asked for with regard to logo_uri and organization_name. For that part I’m really satisfied!

I’m still missing a display_name parameter. In at least for OPs. I think it would really make sense and it would be well motivated by federation specification.

‌

Let me add another nit while we talk about metadata properties.

I think I understand what should go into “contacts”, but I think it cold be more elaborate. I read it as each contact person/function should be expressed in one string and that each string represents a different contact. So a contact String could be anything like:

“John Doe, Customer Support, Example Inc, Merry Lane 10, 123456 Chicago, [e-mail]

I think the text could be more elaborate and an example would be great. However, having such free structure, I think it would be one of the last metadata parameters to be subject to a metadata_policy modifier.

Yet, it is listed as the prime example in 5.1.3

subset_of/superset_of and one_of

subset_of and superset_of apply to parameters that can have more than one value (for instance, contacts), while one_of applies to parameters that can only have one value (for instance,id_token_signed_response_alg). Therefore, one_of cannot appear beside subset_of/ superset_of in a policy entry.

Perhaps you could find a better example for subset_of/superset_of and one_of

[Stefan Santesson]

I do think I slightly disagree with this wording in 4.2.2:

It is RECOMMENDED that, when present, these metadata properties occur in an Entity's federation_entitymetadata section. They MAY also be present in the Entity's metadata for other Entity Types, particularly when the values for those Entity Types differ from those for the federation_entity metadata.

This seems to suggest that Leaf entities should divide their metadata parameters over different entity types. I don’t think that is optimal. If issue an EntityStatement for an OP or RP, I would prefer not to include a Federation entity metadata object for some parameters. Not if the OP has no other role other than being an OP. I would also think that the general RP would like to get just the OP metadata. Yet another reason not to do so is to support the resolve endpoint. A request to the resolve endpoint may include a type identifier like openid_provider . I also read the resolve response metadata parameter as that it will only return the resolved metadata for the requested types. In this case the federation endpoint parameters will not be included.

I would just say that these metadata parameters (it says properties all over 4.2 but I the term is parameters right?) can be added to any entity type. And no more.

[Giuseppe De Marco]

@Stefan regarding the contacts we had this issue FYI
https://bitbucket.org/openid/connect/issues/1993/not-clear-how-to-specify-type-of-contact

Regarding the resolve endpoint response, interesting. I suggest to include in the response, when made available in the Trust Chain, also the federation_entity metadata. This requires a PR.

[Giuseppe De Marco]

PR here
https://bitbucket.org/openid/connect/pull-requests/670

[Stefan Santesson]

I was hoping for another resolution to this. As I responded to this PR. I don’t want to change the resolve response. I think it is fine.

I do however think that this is an argument why metadata for an entity role should be expressed in the metadata for that role, and not spread out over several entity types. That feels messy to me.

[Giuseppe De Marco]

In Italy we definitively decided to have all the administrative metadata in the federation_entity metadata

This Is a impl choice since It Is not mandatory for the leaves

Whatever you think about this, to have a good harmonization the PR give guidance about the First case

‌

[Stefan Santesson]

Technically both ways work. I guess then that you would have to make that update to the resolve response protocol. I don’t think it is optimal, but I can live with it.

[Michael Jones]

This seems related to https://bitbucket.org/openid/connect/issues/2063. Once that’s addressed, I believe that will also address this issue.

[Michael Jones]

organization_name is no longer multiply defined. It can be used in any Entity Type's metadata.