[WG-UMA] Policy Manager

14 views
Skip to first unread message

Alec L

unread,
Aug 27, 2020, 11:35:01 AM8/27/20
to wg-uma@kantarainitiative.org WG
Hi,
To our discussions, I’ve started to break out just the RO policy manager component of the original wallet spec

Best,
- Alec


—


## 1. Introduction

This document extends [UMA Fedz] in order to specify the interface provided by the AS to the RO for policy management. This is achieved by introducing a Policy Management API specification and client type which represents the RO: the UMA Policy Manager.

This new client type is authorized to use the policy API after being authorized by the RO as the AS. THis is the same mechanism used by an RS to put resources under protection, the RS is issued a PAT by the AS.


This new client provides a few key benefits to an UMA ecosystems
- The AS may delegate policy management user expereince and advicce to another party
- The RO is able to choose this client, where they may not be able to choose an AS or RS. The RO receives a consistent policy management interface
- The RO may manage resources at many AS's to have a complete view of their resources and policy


For example, there are two UMA AS's, one being operated by the Alice's local health authority and one operated by Alice's personal Bank. Alice's resource servers are only able to accept authorization decisions from those RS, effectively Alice must use those RSs to protect her resources. When those AS's support this profile, they give back some agency to Alice in how she manages her resources and policy, and reduce their own need to provide this UX (maybe each AS provides on UMA Policy Manager by defaults, but also accept third party policy management services). Alice may then manage policy across all of her RS's and AS's from a single control panel. 



### 1.1 Notational Conventions

### 1.2 Abstract Flow

```
      +------------------+ 
      |     resource     | 
      |       owner      | 
      +------------------+ 
             |              
             |   
             v 
      +------------------+
      |     Policy       |
      |     Manager      |
      +------+-----------+
             |       
             |       
          manage (a PAT type authz?)   
             |              
             |              
             v              
       +-----------+   
       |   policy  |   
       |    API    |   
       +-----------+   
       +---------------+--+
       |                  |
       |   authorization  |
       |      server      |
       |                  |
       +------------------+
```

This specification uses all of the terms and concepts in [UMAGrant] and [UMA Fedz]. This figure introduces the following new concepts:

- UMA Policy Manager
- Policy API The API presented by the AS to the Policy Manager. This API is OAuth protected



### 1.3 HTTP Usage, API Security, and Identity Context


## 2 Authorization Server Metadata 

TBD



## 3 Policy API 

note: this API is very similar to the permission endpoint, expect the payload includes an RS sub, additional policy condition, and is signed by a RO-RS credential

The API available at the policy_endpoint enables the policy manager the modify policy over the RO's protected resources. These policies define the claims gathering requirements for an RqP to gain access to the resource, and should also indicate the intended purpose/use for resource access. Management of the policy beings on successful creation and ends on successful revocation.

The relationship manager uses a RESTful API at the authorization server's policy endpoint to create, read, update, and delete policy descriptions, along with retrieving lists of such descriptions.


note: I think it's also useful to allow the RO to read a list of registered resources, I don't think would live under the policy_endpoint, it's essentially like the GET API from the resource_registration_endpoint with additional information about the RS?

note: through the `   "user_access_policy_uri":"http://as.example.com/rs/222/resource/KX3A-39WE/policy"` the RS could also let the relationship manager know (though manage API) what path to use at the AS to modify policy for this resource?? This restricts


Figure TDB illustrates the policy API operations, with requests and success responses shown.
```
FIGURE TDB
```


- user authz to use the API, same as RS getting a PAT -> continuity of resources, "account at the AS"

- read rs's

- read registered resources
  - organized by RS?

- manage policy
  - resource(s) + acceptable claims conditions



### 4.a Policy Description


A policy is a JSON document, that describes the a policy sufficiently for the authorization server to make a decision for a resource request. A policy document MAY be provided as a signed JWT to ensure it's integrity to the RS during enforcement. A policy description has the following parameters


resource_id REQUIRED The resource id registered at the AS that this policy applies to

resource_scopes REQUIRED The approved scopes if the claims requirements are met

claims REQUIRED An array of claims/attributes that must be presented by the RqP in order to access this resource under this policy



optional/extension/discussion:
sub The subject known by the RS for this RO (useful for general resource definitions)
resource_server (again, useful for general resource definitions)

client_id The client application that may be used to access this resource

intent The purpose/intention of resource use the RqP must accept


For example... 

```
{
  resoruce_id: "KX3A-39WE",
  "resource_scopes": [
      "read-public",
      "post-updates",
  ],
  claims: [
    ???
  ]
}
```

Domenico Catalano

unread,
Aug 27, 2020, 2:19:46 PM8/27/20
to Alec L, wg-uma@kantarainitiative.org WG
Alec,

the today discussion about Policy Manager, it made me remember the In-App authorization widget concept that I’ve introduced (a long time ago) to manage policy, externally to AS.

at this link:

Domenico

--
Domenico Catalano | Cloud Architect | +39.335.725.7896
Oracle Cloud 
via Amsterdam, 147 - 00144 Rome - Italy


Adrian Gropper

unread,
Aug 27, 2020, 7:47:13 PM8/27/20
to Domenico Catalano, wg-uma@kantarainitiative.org WG
Domenico,

This anticipates W3C Verifiable Credentials by about 8 years. https://en.wikipedia.org/wiki/Verifiable_credentials and https://www.w3.org/TR/vc-data-model/

This standard enables automated policy decision at the AS to an unprecedented extent. I'm not aware of anything close as a foundation since VCs are now being profiled in education and beyond. In the EU, where the regulations (eIDAS, and more) are still stuck in XML history, there's active consideration for how to move to JSON because of VCs.

Here's hoping that our work on UMA takes this into account.

- Adrian

https://kantarainitiative.org/mailman/listinfo/wg-uma

Alec Laws

unread,
Sep 2, 2020, 8:37:45 AM9/2/20
to wg-uma@kantarainitiative.org WG
Hi Dominico,

This is awesome, thank you for sharing! A great example of what this relationship manager/policy manager would allow though an AS hosted Policy API


On the RO side,
The policy setting widget at the RS, this could be the RS using the policy api directly after registering the resources. (RS as the policy manager)
The widget could also be provided by a separate policy management service, using the same API provided by the AS, the provides the ui/ux in the widget. The RS could allow the RO to specific the widget provider

On the RqP side, 
If you look at the full relationship manager draft text, this was a mechanism for the RqP to authenticate and provide claims to the AS without necessarily having a direct account there. After being redirected to the AS for interactive claims gathering, the AS would federate to an IDP, either provided by the RqP or the one required by Alice’s policy. This part was the source of a lot of the 'cascading AS' discussion. I've reproduced this diagram below [1], see the 'claims gathering api (OIDC)’ box


Best,
- Alec




[1] 
```
                  +------------------+        +------------------+
                  |     resource     |        |    requesting    |
    +----------   |       owner      |        |      party       |
    |             +------------------+        +------------ -----+
    |
    |                                delegation
    |
    |                              +------------------+
    |                              |   Relationship   |
    |      +-----manage  ----------      Manager      |
    |      |                       +------+-----------+
    |      |                              |       +-----------+
    |      |                              |       |  claims   |
    |      |                              |       | gathering |
    |      |                              |       |  API(OIDC)|
    |      |                           protect    +-----------+
    |      |                              |              ^
    |      |                              |              |
    |      |                              |              |
    |      v                              v              |
    |  +-----------+    protection       +-----------+   |
    |  |  manange  |    API access       |   policy  |   |
    |  |    API    |    token (PAT)      |    API    |   |
    +  +-----------+                     +-----------+   |
   +------------+             +----------+---------------+--+
   |            |             |protection|                  |
   |  resource  |             |   API    |   authorization  |
   |   server   |<---protect--| (needs   |      server      |
   |            |             |   PAT)   |                  |
   +------------+             +----------+------------------+
```

Reply all
Reply to author
Forward
0 new messages