Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion draft-parecki-oauth-client-id-metadata-document.md
Original file line number Diff line number Diff line change
Expand Up @@ -151,7 +151,8 @@ the client to the user in an authorization consent screen, for example the
client name and logo.

The authorization server SHOULD fetch the document indicated by the `client_id`
to retrieve the client registration information.
to retrieve the client registration information. The Authorization Server MUST
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why MUST? Typically a server can ignore the accept header and return whatever it wants... perhaps it is better to specify this as:

When the client_id is an HTTP Resource identifier, the Client ID Metadata Document Service MUST respond with a Content-Type header of application/json.

Also not sure if this fetching is supposed to work over protocols that do not support headers.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a MUST for the reasons noted in #30 — the CIMD Service is also entirely optional. Having the AS send the Accept header, even if the server hosting the CIMD ignores it, allows at least for servers to go "nah, we really don't accept that request" and allow for early termination.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We also already have language around the response content-type in the document.

send an `Accept` header of `application/json` when fetching the client metadata.

## Client Metadata

Expand Down