Additional metadata fields for Client Identifier Documents

[ThisIsMissEm]

I've been reading through some issues and other specifications, and I'm wondering if it would make sense or be possible for us to define some additional fields for the Client Identifier documents. In the SAI working group, they have the concept of an application description and application author. I think the latter is covered by the contacts field in the Client Identifier documents, but the former, a description of the client is currently only kind of covered by the client_uri value (the homepage).

I think it'd make sense to add a string value of client_description to the client identifier documents, I'm not sure if this is something this spec can do, as from what I understand it, the fields need to be registered in the IANA Registry, however, I think from a user perspective, being able to see a short textual description of the application may be helpful when displaying the consent screen.

This would, I think, reduce the gap between solid-oidc and SAI's need for an application profile document, as noted in solid/data-interoperability-panel#210 (comment)

(addendum: I did try to find an existing issue prior to opening this one, but didn't find anything that concretely was this specifically).

[acoburn]

There is already a way to extend the fields in a client ID document, and it uses standard JSON-LD mechanisms. For example:

{
  "@context": [
        "https://www.w3.org/ns/solid/oidc-context.jsonld",
        "https://www.example.com/my-context.jsonld"
    ],

  "client_id": "https://app.example/id",
  "client_name": "Solid Application Name",
  "redirect_uris": ["https://app.example/callback"],
  "post_logout_redirect_uris": ["https://app.example/logout"],
  "client_uri": "https://app.example/",
  "logo_uri" : "https://app.example/logo.png",
  "scope" : "openid offline_access webid",
  "grant_types" : ["refresh_token","authorization_code"],

  "client_description": "A description of the app",
  "custom_property": "some value",
  "other_property": "some other value"
}

Since the Solid-OIDC specification cannot anticipate all possible fields that an app or a user would like to put into a client identifier document, the only thing we really can do is define those properties that align specifically with the relevant OIDC specification. IOW, unless a new field is added in the Dynamic Client Registration specification, I don't think it will be added to the Solid-OIDC context.

Note: there are some fields that are defined by the Dynamic Client Registration specification but which are not present in the Solid-OIDC context. Those could be added, but we also need to figure out the potential role of OIDC Federation, mentioned in #199