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 alec@identos.ca
On May 27, 2020, at 11:11 PM, Alec L <alec@identos.ca> wrote:
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/ <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
