Hi,
To start on the Resource Definitions profile, I've listed changes against the UMA specs.
Cheers,
- Alec
---
# UMA Resource Definitions
## 1. Introduction
This document specifies a profile of UMA Grant and UMA Fedz in order to support Resource Server discovery through AS first flows Client flows. This is enabled by general resource definitions by the Authorization Server.
# Profile UMA Grant
### 1.3 Abstract Flow
```
participant "client" as client
participant "authorization server" as as
client -> as: Permission ticket request (PAT)
as --> client: response with permission ticket
...
client -> as: RPT request with permission ticket
as -> as: authz assessment
as --> client: Response with RPT and resource_location
client -> rs: resource_location with RPT
rs --> client: Protected resource
```
#### 1.3.1 Authorization Process
"interactive claims gathering with an end-user requesting party" - allows the RqP to dynamically select the RS to fulfill
"claims pushing" - only works if the RqP had previously setup some policy with the AS
## 2. Authorization Server Metadata
uma_profiles_supported REQUIRED Include the uri to this profile
#### 3.3.5 Authorization Server Response to Client on Authorization Success
This endpoint can stay unchanged given
- the client requested one resource
or
- the client requested multiple resources
The authorization server MUST add the following parameters to its response:
resource_location REQUIRED The uri registered by the RS during it's resource declaration OR the
- another option is the RPT is a JWT and the `aud` is the resource_location?
*EXTENSION TERRITORY:*
If the client requested multiple resources, ideally the user can fulfill each one with a different specific RS AND the client can still be issued RS-constrained RPTs
Options:
- issue a PCT and let the client requests constrained access token by including a resource indicator in the request
- pack the access token JWT with constrained RPTs. Allows token endpoint to conform, but additional client processing of the response (already happening for the resource_location)
# Profile UMA Fedz
This profile allows the AS to maintain general resource definitions that:
- an RS subscribes to fulfill
- an Client requests permission to
### 1.3 HTTP Usage, API Security, and Identity Context
- RS has a PAT through client credentials, not associated with any user. The RS can declare supported general resources this way
### 3.2.1 Create Resource Description
- type is REQUIRED and must match one of the AS resources
OR
- the RS POST against the AS resource path `as_rreg/_id`
The RS MAY include an additional parameter:
resource_location OPTIONAL The path at the RS that supports this resource type
#### 3.2.5 List Resource Descriptions
alt:
- without the PAT, the AS returns it's resource ids
- AS has a second path for it's general resource types
- types are defined at an external service
## 4. Permission Endpoint
The permission endpoint is opened to the client to call directly.
The client has a PAT using client credentials, same as the RS
- could also introduce a new scope uma_client, uma_permission
### 4.1 Resource Server (*Client*) Request to Permission Endpoint
The client uses the resource_id's and resource_scopes listed at the AS's open resource endpoint
### 4.2 Authorization Server Response to Resource Server (*Client*) on Permission Request Success
The ticket MAY be reused by the client. Maybe not necessary, but convenient?
### 4.3 Authorization Server Response to Resource Server (*Client*) on Permission Request Failure
In addition to existing error_code, the AS may prevent specific clients from access to existing resources and scope
- request_denied?
