—
# UMA Wallet
## 1. Introduction
This document extends [UMA Fedz] in order to specify the management and control interfaces through the UMA Wallet.
The UMA Wallet provides the end-user the consent management interface.
It may be used across multiple ASs, where the user(RO/RqP) is able to choose an independent policy management service, or tightly coupled to a single AS.
In some profiles, this extensions enables the AS to operate with a minimum of collected personal data.
The UMA Wallet operates in two distinct modes, for the RO and the RqP.
The UMA Wallet performs three major flows with other systems:
1. RO puts resources under protection
2. RO creates policy
3. RqP performs claims gathering,
### 1.1 Notational Conventions
### 1.2 Abstract Flow
```
+------------------+ +------------------+
| resource | | requestinng |
+---------- | owner | | party |
| +------------------+ +------------ -----+
|
| delegation
|
| +------------------+
| | |
| +-----manage ---------- Wallet |
| | +------+-----------+
| | | +-----------+
| | | | claims |
| | | | gathering |
| | | | API(OIDC)|
| | | +-----------+
| | | ^
| | | |
| | | |
| v v |
| +-----------+ protection +-----------+ |
| | manange | API access | policy | |
| | API | token (PAT) | API | |
+ +-----------+ +-----------+ |
+------------+ +----------+---------------+--+
| | |protection| |
| resource | | API | authorization |
| server |<-----prot---|-(needs | server |
| | | PAT) | |
+------------+ +----------+------------------+
```
This specification uses all of the terms and concepts in [UMAGrant] and [UMA Fedz]. This figure introduces the following new concepts:
- UMA Wallet
- Policy API
The API presented by the AS to the Wallet. This API is OAuth protected
- Manage API
The API presented by the RS to the Wallet. This API is OAuth protected
### 1.3 HTTP Usage, API Security, and Identity Context
## 2 Authorization Server Metadata
## 3 Manage Endpoint
The management API allows the wallet to manage resources on behalf of the authenticated resource owner.
The manage API allows the RO to register credentials (public keys... or otherwise) the RS will trust policy signed by. The policy is delivered by the AS to to RS in the RPT or through introspection.
The manage API may be extended to allows the wallet
- to read available resources,
- direct the RS to register resources at a specific AS,
- register many identifiers against a public key
### 3.1 Create Credential
Example
```
POST /credential
Authorization: Bearer something
{ oauth dyn client reg with a embedded jwk }
{ a DIDDocument... }
```
## 4 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 policy API allows the wallet to create policy at the AS on behalf of the resource owner.
The policy API may allow the wallet to read available resources or policy types
The wallet uses a RESTful API at the authorization server's policy endpoint to create, read, update, and delete policy, along with retrieving lists of such descriptions.
### 4.1 Policy Description
The policy is a JWT signed by a RO credential known to the RS that owns the resource_id
Example Payload
```
{
"sub": "a RO chosen sub to identify to the RS"
"resource_scopes":[
"view",
],
"resource_id": "resource_id",
...extension/optional
"client_id":
"resource_server": "req'd for res def profile"
"other_conditions"
""
}
```
## 5 Claims Gathering (OIDC)
THe claims gathering API allows the AS to delegate RqP authenticate and claim collection to the Wallet. The wallet allows the RqP to respond to a registered RO policy for the requested resource.