!!! Overview
%%information
[{$pagename}] is currently [draft-hardjono-oauth-resource-reg-07|https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-07|target='_blank']
%%
There are various circumstances under which an [OAuth 2.0] [Resource Server] may need to communicate information about its [Protected Resources] to its [Authorization Server]:

In some [OAuth 2.0] deployments, the resource server and [Authorization Server] are operated by the same organization and deployed in the same domain, but many [Resource Servers] share a single [Authorization Server] (a security token service (STS) component). Thus, even though the trust between these two is typically tightly bound, there is value in defining a singular standardized resource protection communications interface between the [Authorization Server] and each of the [Resource Servers].

In some deployments of [OpenID Connect], which has a dependency on [OAuth 2.0], the [OpenID Provider (OP)|Identity Provider (IDP)] component is a specialized version of an OAuth [Authorization Server] that brokers availability of user attributes by dealing with an ecosystem of attribute providers (APs). These [Attribute Providers] effectively function as third-party [Resource Servers]. Thus, there is value in defining a mechanism by which all of the third-party [Attribute Providers] can communicate with a central [OpenID Provider (OP)|Identity Provider (IDP)], as well as ensuring that trust between the [Authorization Server] and [Resource Servers] is able to be established in a dynamic, loosely coupled fashion.

In some deployments of [User Managed Access|User-Managed Access] [UMA], which has a dependency on [OAuth 2.0], an end-user [Resource Owner] (the "user" in UMA) may choose their own [Authorization Server] as an independent cloud-based service, along with using any number of [Resource Servers] that make up their "[Personal Cloud]". Thus, there is value in defining a mechanism by which all of the third-party [Resource Servers] can outsource resource protection (and potentially [discovery|Discovery Mechanism]) to a central [Authorization Server], as well as ensuring that trust between the [Authorization Server] and [Authorization Server] is able to be established by the [Resource Owner] in a dynamic, loosely coupled fashion.

The [OAuth 2.0 Resource Set Registration|https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html|target='_blank'] defines an API through which the [Resource Server] can register information about [Resource Sets] with the [Authorization Server].

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