This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
Auth 2.0 Resource Set Registration
Auth 2.0 Resource Set Registration

Version management

Difference between version and

At line 1 added 17 lines
!!! 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' }]
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop