[WG-UMA] Wallet extension, concept/flow

[Alec L]

Hi all, 

Tried to show the concept + flows for the Wallet/SSI extensions

- Alec

ps, don’t think I can attach images. The diagrams are plantuml, can paste them into a site to render the image (ex https://www.planttext.com/)

---

## Wallet 

General concept:

An AS can maintain the RS/Client decoupled pattern from first profile, but without see RO/RqP identity data or being able to track service use.  (The AS doesn't support claims pushing/a pct, purely transactional)  The AS delegates authentication and authorization/policy management to a user selected Wallet. 

The Wallet role allows a user to interoperate between using a RS (sources of data/issuer) in an UMA API world, or a direct VC presentation world.  The verifier may still be decoupled from the issuer through trust in the AS

Note, haven't really considered this half of the profile without general resource definitions

```

@startuml

component "Authorization\nServer" as np

component "Client" as consumer

component "Resource\nServer (Issuer)" as provider

component "Wallet" as wallet

component "Verifier" as v

wallet <-> np : Control

np <-> consumer: UMA

provider --> np : UMA\nintrospection

provider --> wallet  : issue

provider --> consumer  : Resource

wallet --> v: present 

np <.. v: trust

@enduml

```

### Description of Flow:

On claims gathering, the AS will forward the authorization request to a RqP selected wallet provider using OIDC

The Wallet 'underwrites' a dynamic client registration for a RO/RqP. Any RO/RqP can have many clients at the AS

The Wallet presents the authorization policy management ux to the User

The Wallet collects connections to RS's and resources for the User (leads to issued VCs), and establishes resource owner credentials

The Wallet creates User policy with the resource owner credentials, and writes it to the AS

The Wallet responds the AS OIDC request with a token including the policy

The AS issues an RPT based on the policy

The RS uses the client credentials and policy to determine Users access

```

@startuml

skinparam shadowing false

autonumber

actor "Requesting\nParty" as C

participant "Authorization\nServer" as NP

participant Wallet as W

participant "Resource Server" as RS

C -> NP: UMA: Claims Gathering (ticket [,wallet]) 

NP --> C: list of wallet

C -> NP: select wallet    

NP -> W: OIDC  Request (ticket/request details)

C <--> W: Authenticate

alt RqP Needs RS Connection

W -> RS: OIDC Request

C <--> RS: authenticate, authorize wallet for resource mngment

RS --> W: access token, userinfo

W <--> RS: resource owner credentials

end

C -> W: Approve permissions

W -> W: Create policy using resource owner credentials

W -> NP: record policy with User Token

W --> NP: 302 Authorize Result IDToken{policy[]}

NP --> C: 302 client, ticket

C -> NP: /token (ticket)

NP --> C: RPT

C -> RS: /resource (RPT)

RS <--> AS: introspection (RPT)

RS -> RS: determine RO using client credentials

RS -> C: RO resource

@enduml      

```

Alec Laws

[Alec L]

Hi,

Please find some updated diagrams and further description

Best,

- Alec

## uma wallet

### Setup

- user registers public key with RS

- user registers public key with AS

- user creates policy to AS with these keys 

- user interaction with RS, AS is facilitation by wallet service

- oauth client for user registration

- oauth provider for service requests

- client has relationship to AS(,RS)

- RS/AS have UMA RS relationship

- RS/Wallet may have UMA RS relationship

### Flow

The RqP is using a client and wants to provide access to a resource

(The client does not have claims to push)

The client sends the RqP to the AS for claims gathering

*start extension*

- The AS sends the RqP to the wallet using... OIDC/UMA claims gathering

- User manages RS resources at the Wallet and Policy at the Wallet.

- User creates approves and creates policy at the AS through the Wallet.

- Wallet responds to AS request, AS is given tx policy

*end ext*

AS callback to Client with ticket…

Alec Laws

647 822 1529

al...@identos.ca