You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: draft-ietf-oauth-client-id-metadata-document.md
+17-9Lines changed: 17 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -34,6 +34,7 @@ normative:
34
34
RFC6749:
35
35
RFC6819:
36
36
RFC7591:
37
+
RFC8259:
37
38
RFC8414:
38
39
RFC9700:
39
40
@@ -151,9 +152,20 @@ the client to the user in an authorization consent screen, for example the
151
152
client name and logo.
152
153
153
154
The authorization server SHOULD fetch the document indicated by the `client_id`
154
-
to retrieve the client registration information. A successful response MUST use the 200 OK HTTP status code and return a JSON object using the `application/json` or `application/<AS-defined>+json` content type. The authorization server MUST treat all other HTTP status codes and content types as an error response. The authorization server MUST NOT automatically follow redirects given via the Location header in responses.
155
+
to retrieve the client registration information. A successful response MUST use
156
+
the 200 OK HTTP status code, have the content type of `application/json` or a more
157
+
specific content type that conforms to `application/<AS-defined>+json`, and be a
158
+
valid JSON object {{RFC8259}}. The authorization server MUST treat all other
159
+
HTTP status codes and content types as an error response. The authorization
160
+
server MUST NOT automatically follow HTTP redirects when retrieving the client
161
+
registration information.
155
162
156
-
## Client Metadata
163
+
If authorization server encounters an error response when retrieving the client
164
+
registration information, the authorization server SHOULD abort the
165
+
authorization request. The authorization server MAY use error responses to
166
+
inform their security policies.
167
+
168
+
## Client Metadata Documents
157
169
158
170
The client metadata document URL is a JSON document containing the metadata
159
171
of the client. The client metadata values are the values defined in
@@ -166,7 +178,8 @@ defined in [RFC3986] Section 6.2.1.
166
178
167
179
The client metadata document MAY define additional properties in the response.
168
180
The client metadata document MAY also be served with more specific content types
169
-
as long as the response is JSON and conforms to `application/<AS-defined>+json`.
181
+
as long as the response is a valid JSON object and the content type conforms to
182
+
`application/<AS-defined>+json`.
170
183
171
184
As there is no way to establish a shared secret to be used with client metadata
172
185
documents, the following restrictions apply on the contents of the
@@ -194,16 +207,11 @@ When developing applications against an authorization server which uses this spe
194
207
195
208
To enable developers to author applications on their machines, without exposing their machines to the public internet, the usage of Client ID Metadata Document Services by the authorization server is RECOMMENDED.
196
209
197
-
A Client ID Metadata Document Service is a web service through which developers can acquire a stable URL to a Client ID Metadata Document. This service MAY expire clients from time to time, and MAY require developers to provide additional information about the client being developed.
210
+
A Client ID Metadata Document Service is a web service through which developers can acquire a stable URL to a Client ID Metadata Document. This service MAY expire clients from time to time, and MAY require developers to provide additional information about the client being developed. The only requirement on Client ID Metadata Document Services is that they MUST return valid Client ID Metadata Documents for the `client_id` that they provision, or return a status code indicating an error response (e.g., 404 Not Found). How a Client ID Metadata Document Service creates or stores metadata documents is outside of the scope of this document.
198
211
199
212
200
213
By providing at least one Client ID Metadata Document Service, an authorization server can enable developers to create applications, and still indicate to non-technical people that the client that they are about to authorize is currently under-development and may not be trustworthy or secure.
201
214
202
-
## Metadata Discovery Errors
203
-
204
-
If fetching the metadata document fails, the authorization server SHOULD abort the
205
-
authorization request.
206
-
207
215
## Metadata Caching
208
216
209
217
The authorization server MAY cache the client metadata it discovers at the
0 commit comments