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?