Not clear how to specify type of contact (e.g. "support", "admin", or "security")

[Nicolas Liampotis]

Section 4.7 defines contacts as a "JSON array with one or more strings representing contact persons at the Entity. These MAY contain names, e-mail addresses, descriptions, phone numbers, etc.".

However, while this definition is flexible and allows for multiple types of contact information, all the examples in the specification represent contacts as arrays containing one or more email addresses. As a result, it is unclear how to properly represent a more complex contact person, which may include a name, description, and additional details.

Would you consider including such an example in the specification? For instance, it would be helpful to include an example containing security contact information which is typically required for entities complying with security frameworks like Sirtfi.

Additionally, it would be valuable for the specification to consider introducing a standardised vocabulary for contact types. See for example the Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0 that defines contact types such as "support," "administrative," etc.

[Giuseppe De Marco]

Hi Nicolas,

I find this issue very interesting. I think that this helps a lot in finding a better definition for the contacts schema, if there will be the possibility to have a list of json objects instead of anonymous strings

the json object could be something like

{
  "given_name": "",
  "family_name": "",
  "email": "",
  "phone_number": "",
  "contact_type" ...
}

while for the compliance proof given by Sirtfi we could explore how the Trust Marks may help.
If I got your point, the “extended” contacts are needed for the issuance of the sirtifi trust mark, so it should be published in the metadata before the issuance of the sirtifi trust mark.

At the same time there may be other frameworks that requires other/different information that could be in collision (even if it is rare for the contacts information, I admit).

The Trust Marks avoids this problem since each TM is on their own, without inflating the metadata. Please add your reaction on this, then this issue will be discussed in the next editor’s call and an action will be taken

[Michael Jones]

OpenID Connect Registration defines contacts as:

contacts

OPTIONAL. Array of e-mail addresses of people responsible for this Client. This might be used by some providers to enable a Web user interface to modify the Client information.

This is also an array of strings, so I’m prone to not change this definition to use another data type.

If you want structured contacts, I’d suggest defining a new metadata identifier for them, such as structured_contacts. That could be an extension defined by a profile, since ultimately the contents are intended to be human-readable. It need not be in the Federation spec itself.

I propose that we close this issue on that basis.

[Roland Hedberg]

I agree with @Michael Jones that this is not something that should appear in the Federation spec.

It’s typically something that should be defined in a profile of the OIDC core documents.

There is a R/E working group within OpenID (https://openid.net/wg/rande/) that was tasked to:

“The R&E working group is creating a set of profiles for the OpenID Connect specifications to ease adoption in the Research and Education (R&E) sector.”

I think defining new metadata claims, such as structured_contacts, should be a task for that group.

[Michael Jones]

This is an extension that another specification or profile could create but it needn't be in the core specification.