!!! Overview
[{$pagename}] extended [OAuth 2.0 Dynamic Client Registration Protocol] with [REST]ful operations to permit retrieval (via [HTTP GET]), modification ([HTTP PUT]) and deletion ([HTTP DELETE]) of an [OAuth 2.0 Client Registration].

[{$pagename}] when it was an [Internet Draft] and was combined with [OpenID Connect Dynamic Client Registration] into [{$pagename}] as [RFC 7592].!! Security Considerations
While the client secret can expire, the [Registration Access Token] __SHOULD NOT__ expire while a [OAuth Client] is still actively registered.  

If this [Registration Access Token] were to expire, a developer or [OAuth Client] could be left in a situation where they have no means of retrieving, updating, or deleting the [OAuth Client]'s registration information.  Were that the case, a new registration would be required, thereby generating a new [client identifier|client_id].  However, to limit the exposure surface of the [Registration Access Token], the [Registration Access Token] MAY be rotated when the developer or [OAuth Client] does a read or update operation on the [OAuth Client]'s client configuration endpoint.  As the [Registration Access Tokens] are relatively long-term [credentials], and since the [Registration Access Token] is a [Bearer Token] and acts as the sole [authentication] for use at the client configuration endpoint, it __MUST__ be protected by the developer or [OAuth Client] as described in the [OAuth 2.0 Bearer Token Usage] specification [RFC 6750].

Since requests to the client configuration endpoint result in the transmission of clear-text [credentials] (in the HTTP request and response), the [authorization Server] __MUST require__ the use of a [Transport Layer Security] mechanism when sending requests to the endpoint. The server __MUST__ support [TLS 1.2] ([RFC 5246]) and __MAY__ support additional transport-layer security mechanisms meeting its security requirements.  When using [TLS], the client __MUST__ perform a [TLS]/[SSL] server [certificate check|Certificate Validation], per [RFC 6125].  Implementation security considerations can be found in Recommendations for Secure Use of [TLS] and [DTLS] [BCP195].

Since possession of the [Registration Access Token] authorizes the holder to potentially read, modify, or delete a client's registration (including its credentials such as a client_secret), the [Registration Access Token] __MUST__ contain sufficient [entropy] to prevent a random guessing attack of the [Registration Access Token], such as described in Section 5.2 of [RFC 6750] and Section 5.1.4.2.2 of [RFC 6819].

If a [OAuth Client] is deprovisioned from a server, any outstanding [Registration Access Token] for that [OAuth Client] __MUST__ be invalidated at the same time.  Otherwise, this can lead to an inconsistent state wherein a [OAuth Client] could make requests to the client configuration endpoint where the [authentication] would succeed but the action would fail because the [OAuth Client] is no longer valid.  The [authorization Server] __MUST__ treat all such requests as if the [Registration Access Token] was invalid by returning an [HTTP 401] Unauthorized error, as described.

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]