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