Hi Mark, In my mind, yes. The Wallet is the policy/consent/authorization management dashboard for the person, including personal private key management capabilities. As an independent and user chosen service, it can work between many RS/AS ecosystems. Another vague thought is that the response to posting policy from Wallet->AS could return an executed consent receipt Cheers, - Alec Alec Laws 647 822 1529 alec@identos.ca

On Jul 8, 2020, at 11:51 PM, Mark Lizar wrote:

A quick question, thinking about this.

Technically, would this wallet be a consent ‘grant' manager for UMA ? As legally people (are suppose) to be the managers of consent - which is used to grant permissions. This comes up with ISO 29184 now published (June 06) which makes it easier to assess the consent record structure and the permissions granted with a consent in an identity management system.

Best,

Mark

...

On 8 Jul 2020, at 23:22, Mark Lizar mailto:mark@openconsent.com> wrote:

This looks Great !! (So clean and simple)

- Mark

...

On 8 Jul 2020, at 23:02, Alec L mailto:alec@identos.ca> wrote:

Hi, please find a first go at ’spec text’ for UMA wallet below

Cheers, - Alec

— # 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.

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma https://kantarainitiative.org/mailman/listinfo/wg-uma

I think we're confusing user agent with (user) agent. The majority of user agents look like stateless browsers and have no storage for policies, consent receipts, or anything else. This is obvious even for user agents like email where Firefox moved Thunderbird out years ago and Gmail has done quite well compared to Apple's Mail. 1Password and AdBlock do have storage and policies respectively but they are not agents in the sense of an on-line presence as a policy decision point. The accurate and authentic rendering of my policies is definitely a job for my browser as MY user agent. The storage of my policies, in the UMA sense, needs to be by an agent which is an authorization server, on-line. This AS might or might not be "owned" by me in the hosting sense. UMA just says: "The AS is not the same entity as the RS". Which brings us to the API between my user agent and my agent (the UA2A API) and the possible role of standards and consent receipts for this UA2A API. I suggest that UA2A is out of scope for UMA, with or without consent receipts. If the AS wants to issue a receipt for policy updates or any other transactions it is party to, it should do so and send them straight to some storage, like my email or phone SMS. - Adrian On Thu, Jul 9, 2020 at 5:47 PM Mark Lizar wrote:

Your mind looks like a great place IMO,

This is essentially it, the execution of a consent receipt - this is the spot I think where interop and conformance is required to progress meaningfully. (In my mind at least) This component is under-developed to say the least.

Perhaps an update reflecting this place - would be appropriate ? I link the consent grant is executed and a receipt links providence of the grant - to transparency over its execution - kinda like how a receipt works already .

- M

On 9 Jul 2020, at 17:31, Alec L wrote:

Hi Mark,

In my mind, yes. The Wallet is the policy/consent/authorization management dashboard for the person, including personal private key management capabilities. As an independent and user chosen service, it can work between many RS/AS ecosystems. Another vague thought is that the response to posting policy from Wallet->AS could return an executed consent receipt

Cheers, - Alec

Alec Laws 647 822 1529 alec@identos.ca

On Jul 8, 2020, at 11:51 PM, Mark Lizar wrote:

A quick question, thinking about this.

Technically, would this wallet be a consent ‘grant' manager for UMA ? As legally people (are suppose) to be the managers of consent - which is used to grant permissions. This comes up with ISO 29184 now published (June 06) which makes it easier to assess the consent record structure and the permissions granted with a consent in an identity management system.

Best,

Mark

On 8 Jul 2020, at 23:22, Mark Lizar wrote:

This looks Great !! (So clean and simple)

- Mark

On 8 Jul 2020, at 23:02, Alec L wrote:

Hi, please find a first go at ’spec text’ for UMA wallet below

Cheers, - Alec

— # 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.

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma