Merge e679a00720 into 22f3cc009b

changelogs/client_server/newsfragments/2320.feature

@@ -1 +0,0 @@
-Add the OAuth 2.0 Device Authorization Grant (RFC 8628) as a supported grant type, as per [MSC4341](https://github.com/matrix-org/matrix-spec-proposals/pull/4341).

changelogs/client_server/newsfragments/2336.clarification

@@ -1 +0,0 @@
-Order the common and other error codes alphabetically and remove duplicate `M_THREEPID_IN_USE` definition.

changelogs/identity_service/newsfragments/2336.clarification

@@ -1 +0,0 @@
-Order the standard error codes alphabetically.

content/client-server-api/_index.md

@@ -93,27 +93,48 @@ request being made was invalid.
 
 These error codes can be returned by any API endpoint:
 
-<!-- Please keep the error codes below in alphabetical order -->
+`M_FORBIDDEN`
+: Forbidden access, e.g. joining a room without permission, failed login.
+
+`M_UNKNOWN_TOKEN`
+: The access or refresh token specified was not recognised.
+
+: An additional response parameter, `soft_logout`, might be present on the
+response for 401 HTTP status codes. See [the soft logout
+section](#soft-logout) for more information.
+
+`M_MISSING_TOKEN`
+: No access token was specified for the request.
+
+`M_USER_LOCKED`
+: The account has been [locked](#account-locking) and cannot be used at this time.
+
+`M_USER_SUSPENDED`
+: The account has been [suspended](#account-suspension) and can only be used for
+limited actions at this time.
 
 `M_BAD_JSON`
 : Request contained valid JSON, but it was malformed in some way, e.g.
 missing required keys, invalid values for keys.
 
-`M_FORBIDDEN`
+`M_NOT_JSON`
-: Forbidden access, e.g. joining a room without permission, failed login.
+: Request did not contain valid JSON.
+
+`M_NOT_FOUND`
+: No resource was found for this request.
 
 `M_LIMIT_EXCEEDED`
 : Too many requests have been sent in a short period of time. Wait a while
 then try again. See [Rate limiting](#rate-limiting).
 
-`M_MISSING_TOKEN`
+`M_UNRECOGNIZED`
-: No access token was specified for the request.
+: The server did not understand the request. This is expected to be returned with
+a 404 HTTP status code if the endpoint is not implemented or a 405 HTTP status
+code if the endpoint is implemented, but the incorrect HTTP method is used.
 
-`M_NOT_FOUND`
+`M_UNKNOWN_DEVICE`
-: No resource was found for this request.
+: {{% added-in v="1.17" %}} The device ID supplied by the application service does
-
+not belong to the user ID during [identity assertion](/application-service-api/#identity-assertion).
-`M_NOT_JSON`
-: Request did not contain valid JSON.
 
 `M_RESOURCE_LIMIT_EXCEEDED`
 : The request cannot be completed because the homeserver has reached a
@@ -160,85 +181,39 @@ limit is a hard limit that cannot be increased.
 `M_UNKNOWN`
 : An unknown error has occurred.
 
-`M_UNKNOWN_DEVICE`
-: {{% added-in v="1.17" %}} The device ID supplied by the application service does
-not belong to the user ID during [identity assertion](/application-service-api/#identity-assertion).
-
-`M_UNKNOWN_TOKEN`
-: The access or refresh token specified was not recognised.
-
-: An additional response parameter, `soft_logout`, might be present on the
-response for 401 HTTP status codes. See [the soft logout
-section](#soft-logout) for more information.
-
-`M_UNRECOGNIZED`
-: The server did not understand the request. This is expected to be returned with
-a 404 HTTP status code if the endpoint is not implemented or a 405 HTTP status
-code if the endpoint is implemented, but the incorrect HTTP method is used.
-
-`M_USER_LOCKED`
-: The account has been [locked](#account-locking) and cannot be used at this time.
-
-`M_USER_SUSPENDED`
-: The account has been [suspended](#account-suspension) and can only be used for
-limited actions at this time.
-
-<!-- Please keep the error codes above in alphabetical order -->
-
 #### Other error codes
 
 The following error codes are specific to certain endpoints.
 
 <!-- TODO: move them to the endpoints that return them -->
 
-<!-- Please keep the error codes below in alphabetical order -->
+`M_UNAUTHORIZED`
+: The request was not correctly authorized. Usually due to login failures.
 
-`M_BAD_STATE`
+`M_USER_DEACTIVATED`
-: The state change requested cannot be performed, such as attempting to
+: The user ID associated with the request has been deactivated. Typically
-unban a user who is not banned.
+for endpoints that prove authentication, such as [`/login`](#get_matrixclientv3login).
 
-`M_CANNOT_LEAVE_SERVER_NOTICE_ROOM`
+`M_USER_IN_USE`
-: The user is unable to reject an invite to join the server notices room.
+: Encountered when trying to register a user ID which has been taken.
-See the [Server Notices](#server-notices) module for more information.
-
-`M_CAPTCHA_INVALID`
-: The Captcha provided did not match what was expected.
-
-`M_CAPTCHA_NEEDED`
-: A Captcha is required to complete the request.
-
-`M_EXCLUSIVE`
-: The resource being requested is reserved by an application service, or
-the application service making the request has not created the resource.
-
-`M_GUEST_ACCESS_FORBIDDEN`
-: The room or resource does not permit guests to access it.
-
-`M_INCOMPATIBLE_ROOM_VERSION`
-: The client attempted to join a room that has a version the server does
-not support. Inspect the `room_version` property of the error response
-for the room's version.
-
-`M_INVALID_PARAM`
-: A parameter that was specified has the wrong value. For example, the
-server expected an integer and instead received a string.
-
-`M_INVALID_ROOM_STATE`
-: Sent when the initial state given to the `createRoom` API is invalid.
 
 `M_INVALID_USERNAME`
 : Encountered when trying to register a user ID which is not valid.
 
-`M_MISSING_PARAM`
-: A required parameter was missing from the request.
-
 `M_ROOM_IN_USE`
 : Sent when the room alias given to the `createRoom` API is already in
 use.
 
-`M_SERVER_NOT_TRUSTED`
+`M_INVALID_ROOM_STATE`
-: The client's request used a third-party server, e.g. identity server,
+: Sent when the initial state given to the `createRoom` API is invalid.
-that this server does not trust.
+
+`M_THREEPID_IN_USE`
+: Sent when a threepid given to an API cannot be used because the same
+threepid is already in use.
+
+`M_THREEPID_NOT_FOUND`
+: Sent when a threepid given to an API cannot be used because no record
+matching the threepid was found.
 
 `M_THREEPID_AUTH_FAILED`
 : Authentication could not be performed on the third-party identifier.
@@ -248,35 +223,56 @@ that this server does not trust.
 if the server only permits, for example, email addresses from a
 particular domain.
 
-`M_THREEPID_IN_USE`
+`M_SERVER_NOT_TRUSTED`
-: The third party identifier specified by the client is not acceptable because it is
+: The client's request used a third-party server, e.g. identity server,
-already in use in some way.
+that this server does not trust.
-
-`M_THREEPID_MEDIUM_NOT_SUPPORTED`
-: The homeserver does not support adding a third party identifier of the given medium.
-
-`M_THREEPID_NOT_FOUND`
-: Sent when a threepid given to an API cannot be used because no record
-matching the threepid was found.
-
-`M_TOO_LARGE`
-: The request or entity was too large.
-
-`M_UNAUTHORIZED`
-: The request was not correctly authorized. Usually due to login failures.
 
 `M_UNSUPPORTED_ROOM_VERSION`
 : The client's request to create a room used a room version that the
 server does not support.
 
-`M_USER_DEACTIVATED`
+`M_INCOMPATIBLE_ROOM_VERSION`
-: The user ID associated with the request has been deactivated. Typically
+: The client attempted to join a room that has a version the server does
-for endpoints that prove authentication, such as [`/login`](#get_matrixclientv3login).
+not support. Inspect the `room_version` property of the error response
+for the room's version.
 
-`M_USER_IN_USE`
+`M_BAD_STATE`
-: Encountered when trying to register a user ID which has been taken.
+: The state change requested cannot be performed, such as attempting to
+unban a user who is not banned.
 
-<!-- Please keep the error codes above in alphabetical order -->
+`M_GUEST_ACCESS_FORBIDDEN`
+: The room or resource does not permit guests to access it.
+
+`M_CAPTCHA_NEEDED`
+: A Captcha is required to complete the request.
+
+`M_CAPTCHA_INVALID`
+: The Captcha provided did not match what was expected.
+
+`M_MISSING_PARAM`
+: A required parameter was missing from the request.
+
+`M_INVALID_PARAM`
+: A parameter that was specified has the wrong value. For example, the
+server expected an integer and instead received a string.
+
+`M_TOO_LARGE`
+: The request or entity was too large.
+
+`M_EXCLUSIVE`
+: The resource being requested is reserved by an application service, or
+the application service making the request has not created the resource.
+
+`M_CANNOT_LEAVE_SERVER_NOTICE_ROOM`
+: The user is unable to reject an invite to join the server notices room.
+See the [Server Notices](#server-notices) module for more information.
+
+`M_THREEPID_MEDIUM_NOT_SUPPORTED`
+: The homeserver does not support adding a third party identifier of the given medium.
+
+`M_THREEPID_IN_USE`
+: The third party identifier specified by the client is not acceptable because it is
+already in use in some way.
 
 #### Rate limiting
 
@@ -558,7 +554,7 @@ endpoint.
 
 With the OAuth 2.0 API, a client can obtain an access token by using one of the
 [grant types](#grant-types) supported by the homeserver and authorizing the
-proper [scope](#scope), as demonstrated in the [login flows](#login-flows). To
+proper [scope](#scope), as demonstrated in the [login flow](#login-flow). To
 invalidate the access token the client must use [token revocation](#token-revocation).
 
 ### Using access tokens
@@ -1755,31 +1751,19 @@ authentication type.
 
 1. [Discover the OAuth 2.0 server metadata](#server-metadata-discovery).
 2. [Register the client with the homeserver](#client-registration).
-3. [Obtain an access token](#login-flows) by authorizing a [scope](#scope) for
+3. [Obtain an access token](#login-flow) by authorizing a [scope](#scope) for the client with the [authorization code grant](#authorization-code-grant).
-   the client with the [authorization code grant](#authorization-code-grant) or
-   [device authorization grant](#device-authorization-grant).
 4. [Refresh the access token](#token-refresh-flow) with the [refresh token grant](#refresh-token-grant) when it expires.
 5. [Revoke the tokens](#token-revocation) when the users wants to log out of the client.
 
-#### Login flows
+#### Login flow
 
-Logging in and obtaining an access token with the OAuth 2.0 API should be done
+Logging in with the OAuth 2.0 API should be done with the [authorization code
-using either the [authorization code grant](#authorization-code-grant) or
+grant](#authorization-code-grant). In the context of the Matrix specification,
-[device authorization grant](#device-authorization-grant). In the context of the
+this means requesting a [scope](#scope) including full client-server API
-Matrix specification, this means requesting a [scope](#scope) including full
+read/write access and allocating a device ID.
-client-server API read/write access and allocating a device ID.
 
-##### Authorization code flow
+Once the client has retrieved the [server metadata](#server-metadata-discovery),
-
+it needs to generate the following values:
-This login flow uses the [authorization code grant](#authorization-code-grant)
-and is suitable for clients where the following criteria are met:
-
-- There is a web browser available for the user to complete authentication and
-  authorization.
-- The client can receive the callback via a redirect from the web browser.
-
-Once the client has retrieved the [server metadata](#server-metadata-discovery)
-the client needs to generate the following values:
 
 - `device_id`: a unique identifier for this device; see the
   [`urn:matrix:client:device:<device_id>`](#device-id-allocation) scope token.
@@ -1920,143 +1904,6 @@ Sample response:
 Finally, the client can call the  [`/whoami`](#get_matrixclientv3accountwhoami)
 endpoint to get the user ID that owns the access token.
 
-##### Device authorization flow
-
-{{% added-in v="1.18" %}}
-
-This flow uses the [device authorization grant](#device-authorization-grant) to
-allow clients to obtain an access token without needing to directly interact
-with a web browser. Instead, the user completes authorization on a web browser
-that can be a separate device.
-
-This is useful for devices with limited input
-capabilities (such as CLI applications or embedded devices) or where the
-redirect handling may be unreliable (such as a desktop applications).
-
-Once the client has retrieved the [server metadata](#server-metadata-discovery)
-the client needs to generate following value:
-
-- `device_id`: a unique identifier for this device; see the
-  [`urn:matrix:client:device:<device_id>`](#device-id-allocation) scope token.
-
-**Device authorization request**
-
-The client sends a `application/x-www-form-urlencoded` encoded `POST` request to
-the `device_authorization_endpoint` as defined in
-[RFC 8628 section 3.1](https://datatracker.ietf.org/doc/html/rfc8628#section-3.1):
-
-| Parameter   | Value                                                          |
-|-------------|----------------------------------------------------------------|
-| `client_id` | The client ID returned from client registration.               |
-| `scope`     | `urn:matrix:client:api:* urn:matrix:client:device:<device_id>` with the `device_id` generated previously. |
-
-Sample device authorization request:
-
-```
-POST /oauth2/device HTTP/1.1
-Host: account.example.com
-Content-Type: application/x-www-form-urlencoded
-
-client_id=s6BhdRkqt3&scope=urn%3Amatrix%3Aclient%3Aapi%3A%2A%20urn%3Amatrix%3Aclient%3Adevice%3AAABBBCCCDDD
-```
-
-**Device authorization response**
-
-The server responds with a JSON object as defined in
-[RFC 8628 section 3.2](https://datatracker.ietf.org/doc/html/rfc8628#section-3.2),
-containing:
-
-| Parameter                    |                                                                                                                                               |
-|------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------|
-| `device_code`                | The device verification code.                                                                                                                 |
-| `user_code`                  | An end-user verification code.                                                                                                                |
-| `verification_uri`           | The end-user verification URI on the authorization server.                                                                                    |
-| `verification_uri_complete`  | Optionally, the URI which doesn't require the user to manually type the `user_code`, designed for non-textual transmission.                   |
-| `expires_in`                 | The lifetime in seconds of the `device_code` and `user_code`.                                                                                 |
-| `interval`                   | The minimum number of seconds the client should wait between polling requests to the token endpoint. If omitted, clients should default to 5. |
-
-It is RECOMMENDED that the server provides a `verification_uri_complete` such
-that the user does not need to type in the `user_code`.
-
-Sample response:
-
-```json
-{
-  "device_code": "GmRhmhcxhwAzkoEqiMEg_DnyEysNkuNhszIySk9eS",
-  "user_code": "WDJB-MJHT",
-  "verification_uri": "https://account.example.com/link",
-  "verification_uri_complete": "https://account.example.com/link?user_code=WDJB-MJHT",
-  "expires_in": 1800,
-  "interval": 5
-}
-```
-
-**User interaction**
-
-The client conveys the `verification_uri_complete` (and/or `verification_uri`
-and `user_code`) to the user. How the client does this depends on the
-specific device characteristics and use case. For example:
-
-- A CLI application could display the `verification_uri` and `user_code` as text
-  for the user to type into their browser on another device.
-- An embedded device with a screen could encode the `verification_uri_complete`
-  (with fallback to `verification_uri`) as a QR code for the user to scan with
-  their phone.
-- A desktop application running on a platform that does not support callbacks
-  could launch the `verification_uri_complete` (with fallback to
-  `verification_uri`) in the system browser.
-
-The user opens the verification URI in a web browser, which may be on another
-device, and completes authentication and authorization.
-
-**Token polling**
-
-While the user is completing authorization, the client polls the
-`token_endpoint` for the outcome, at intervals no shorter than the `interval`
-value from the device authorization response.
-
-The poll request is a `POST` to the `token_endpoint` with the following
-parameters, encoded as `application/x-www-form-urlencoded` in the body:
-
-| Parameter     | Value                                                          |
-|---------------|----------------------------------------------------------------|
-| `grant_type`  | `urn:ietf:params:oauth:grant-type:device_code`                 |
-| `device_code` | The `device_code` from the device authorization response.      |
-| `client_id`   | The client ID returned from client registration.               |
-
-Sample token polling request:
-
-```
-POST /oauth2/token HTTP/1.1
-Host: account.example.com
-Content-Type: application/x-www-form-urlencoded
-
-grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code&device_code=GmRhmhcxhwAzkoEqiMEg_DnyEysNkuNhszIySk9eS&client_id=s6BhdRkqt3
-```
-
-The server responds as defined in [RFC 8628 section
-3.5](https://datatracker.ietf.org/doc/html/rfc8628#section-3.5):
-
-- While authorization is pending, the server returns an `authorization_pending`
-  error (or `slow_down` if the client is polling too frequently).
-- If authorization is denied, the server returns an `access_denied` error.
-- If the device code expires, the server returns an `expired_token` error.
-- On successful authorization, the server returns a JSON object containing the
-  access token, token type, expiration time, refresh token, and scope:
-
-```json
-{
-  "access_token": "2YotnFZFEjr1zCsicMWpAA",
-  "token_type": "Bearer",
-  "expires_in": 299,
-  "refresh_token": "tGz3JOkF0XG5Qx2TlKWIA",
-  "scope": "urn:matrix:client:api:* urn:matrix:client:device:AAABBBCCCDDD"
-}
-```
-
-Finally, the client can call the [`/whoami`](#get_matrixclientv3accountwhoami)
-endpoint to get the user ID that owns the access token.
-
 #### Token refresh flow
 
 Refreshing a token with the OAuth 2.0 API should be done with the [refresh token
@@ -2387,7 +2234,6 @@ The client must also have obtained a `client_id` by [registering with the server
 
 This specification supports the following grant types:
 - [Authorization code grant](#authorization-code-grant)
-- {{% added-in v="1.18" %}} [Device authorization grant](#device-authorization-grant)
 - [Refresh token grant](#refresh-token-grant)
 
 ##### Authorization code grant
@@ -2412,34 +2258,18 @@ To use this grant, homeservers and clients MUST:
   Encoding Practices](https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html)
   for clients with an HTTPS redirect URI.
 
-##### Device authorization grant
+###### User registration
 
-{{% added-in v="1.18" %}}
+Clients can signal to the server that the user desires to register a new account
+by initiating the authorization code grant with the `prompt=create` parameter
+set in the authorization request as defined in [Initiating User Registration via
+OpenID Connect 1.0](https://openid.net/specs/openid-connect-prompt-create-1_0.html).
 
-As per [RFC 8628](https://datatracker.ietf.org/doc/html/rfc8628), the device
+Whether the homeserver supports this parameter is advertised by the
-authorization grant lets clients on devices with limited input capabilities
+`prompt_values_supported` authorization server metadata.
-obtain an access token by having the user complete authorization on a separate
-device with a web browser.
 
-This grant requires the client to know the following [authorization server
+Servers that support this parameter SHOULD show the account registration UI in
-metadata](#server-metadata-discovery):
+the browser.
-
-- `device_authorization_endpoint`
-
-To use this grant, homeservers and clients MUST:
-
-- Support the device authorization grant as per
-  [RFC 8628](https://datatracker.ietf.org/doc/html/rfc8628).
-- Support the [refresh token grant](#refresh-token-grant).
-
-As with the [authorization code grant](#authorization-code-grant), when
-authorization is granted to a client, the homeserver MUST issue a refresh token
-to the client in addition to the access token. The access token and refresh
-token have the same lifetime constraints as described in the [refresh token
-grant](#refresh-token-grant) section.
-
-The full flow for using this grant is described in the
-[device authorization flow](#device-authorization-flow).
 
 ##### Refresh token grant
 
@@ -2546,22 +2376,6 @@ The server SHOULD return one of the following responses:
 - For other errors, the server returns a `400 Bad Request` response with error
   details
 
-#### User registration
-
-Clients can signal to the server that the user desires to register a new account
-by initiating the [authorization code grant](#authorization-code-grant) with the `prompt=create` parameter
-set in the authorization request as defined in [Initiating User Registration via
-OpenID Connect 1.0](https://openid.net/specs/openid-connect-prompt-create-1_0.html).
-
-Whether the homeserver supports this parameter is advertised by the
-`prompt_values_supported` authorization server metadata.
-
-Servers that support this parameter SHOULD show the account registration UI in
-the browser.
-
-The `prompt=create` parameter is not supported when using the [device
-authorization grant](#device-authorization-grant).
-
 #### Account management {id="oauth-20-account-management"}
 
 {{% added-in v="1.18" %}}

content/identity-service-api.md

@@ -70,7 +70,26 @@ the keys `error` and `errcode` MUST always be present.
 
 Some standard error codes are below:
 
-<!-- Please keep the error codes below in alphabetical order -->
+`M_NOT_FOUND`
+: The resource requested could not be located.
+
+`M_MISSING_PARAMS`
+: The request was missing one or more parameters.
+
+`M_INVALID_PARAM`
+: The request contained one or more invalid parameters.
+
+`M_SESSION_NOT_VALIDATED`
+: The session has not been validated.
+
+`M_NO_VALID_SESSION`
+: A session could not be located for the given parameters.
+
+`M_SESSION_EXPIRED`
+: The session has expired and must be renewed.
+
+`M_INVALID_EMAIL`
+: The email address provided was not valid.
 
 `M_EMAIL_SEND_ERROR`
 : There was an error sending an email. Typically seen when attempting to
@@ -79,39 +98,10 @@ verify ownership of a given email address.
 `M_INVALID_ADDRESS`
 : The provided third-party address was not valid.
 
-`M_INVALID_EMAIL`
-: The email address provided was not valid.
-
-`M_INVALID_PARAM`
-: The request contained one or more invalid parameters.
-
-`M_MISSING_PARAMS`
-: The request was missing one or more parameters.
-
-`M_NO_VALID_SESSION`
-: A session could not be located for the given parameters.
-
-`M_NOT_FOUND`
-: The resource requested could not be located.
-
 `M_SEND_ERROR`
 : There was an error sending a notification. Typically seen when
 attempting to verify ownership of a given third-party address.
 
-`M_SESSION_EXPIRED`
-: The session has expired and must be renewed.
-
-`M_SESSION_NOT_VALIDATED`
-: The session has not been validated.
-
-`M_THREEPID_IN_USE`
-: The third-party identifier is already in use by another user. Typically
-this error will have an additional `mxid` property to indicate who owns
-the third-party identifier.
-
-`M_UNKNOWN`
-: An unknown error has occurred.
-
 `M_UNRECOGNIZED`
 : The request contained an unrecognised value, such as an unknown token or
 medium.
@@ -121,7 +111,13 @@ This is expected to be returned with a 404 HTTP status code if the endpoint is
 not implemented or a 405 HTTP status code if the endpoint is implemented, but
 the incorrect HTTP method is used.
 
-<!-- Please keep the error codes above in alphabetical order -->
+`M_THREEPID_IN_USE`
+: The third-party identifier is already in use by another user. Typically
+this error will have an additional `mxid` property to indicate who owns
+the third-party identifier.
+
+`M_UNKNOWN`
+: An unknown error has occurred.
 
 ## Privacy
 

data/api/client-server/oauth_server_metadata.yaml

@@ -67,7 +67,8 @@ paths:
                     type: string
                     format: uri
                     description: |-
-                      URL of the token endpoint, used by the grants.
+                      URL of the token endpoint, necessary to use the authorization code grant and
+                      the refresh token grant.
                   revocation_endpoint:
                     type: string
                     format: uri
@@ -100,10 +101,6 @@ paths:
                       This array MUST contain at least the `authorization_code` and `refresh_token`
                       values, for clients to be able to use the authorization code grant and refresh
                       token grant, respectively.
-
-                      {{% added-in v="1.18" %}} It MAY also contain
-                      `urn:ietf:params:oauth:grant-type:device_code` to indicate support for the
-                      [device authorization grant](/client-server-api/#device-authorization-grant).
                     items:
                       type: string
                       description: A grant type that the server supports.
@@ -168,14 +165,6 @@ paths:
                         - "org.matrix.account_deactivate"
                         - "org.matrix.cross_signing_reset"
                       description: An action that the account management URL supports.
-                  device_authorization_endpoint:
-                    x-addedInMatrixVersion: "1.18"
-                    type: string
-                    format: uri
-                    description: |-
-                      URL of the device authorization endpoint, as defined in
-                      [RFC 8628](https://datatracker.ietf.org/doc/html/rfc8628), necessary to use
-                      the [device authorization grant](/client-server-api/#device-authorization-grant).
                 required:
                   - issuer
                   - authorization_endpoint
@@ -191,10 +180,9 @@ paths:
                   "authorization_endpoint": "https://account.example.com/oauth2/auth",
                   "token_endpoint": "https://account.example.com/oauth2/token",
                   "registration_endpoint": "https://account.example.com/oauth2/clients/register",
-                  "device_authorization_endpoint": "https://account.example.com/oauth2/device",
                   "revocation_endpoint": "https://account.example.com/oauth2/revoke",
                   "response_types_supported": ["code"],
-                  "grant_types_supported": ["authorization_code", "refresh_token", "urn:ietf:params:oauth:grant-type:device_code"],
+                  "grant_types_supported": ["authorization_code", "refresh_token"],
                   "response_modes_supported": ["query", "fragment"],
                   "code_challenge_methods_supported": ["S256"],
                   "account_management_uri": "https://account.example.com/manage",