June 2021 - WG-UMA - mailman.kantarainitiative.org

Relationship Manager User Stories
by Alec Laws 01 Jul '21

01 Jul '21

Hi, as requested have collected the user stories we've looked at around the Wallet/ Relationship Manager drafts for discussion tomorrow From: https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-11-19 As RqP Bob, I want to be able to request access to a set of Alice's resources directly from Alice's AS without knowledge of their location, because I don't have to bother getting or caring about all the locations from Alice first. As client C used by RqP Bob, want to be able to request access to a set of Alice's resources directly from Alice's AS on Bob's behalf without knowledge of their location, because I don't have to retrieve the locations first. — From: https://groups.google.com/g/kantara-initiative-uma-wg/c/f0g98sr22Rw/m/M5jK9… As a RO, I want to manage my resources independently of each individual RS (UMA core prop) As an AS, I want to decouple the consent management UX from the authorization services, As a RO, I need a personally controlled user-agent (UMA Wallet) to manage my key material, in order to maintain personal-agency in ecosystems As a RO, I want to authorize a "UMA Wallet" to manage RS resources, so that I have a single view into my available RS's and Resources As a RS, I need Alice to authenticate in order to determine which resources she can manage, in order to ensure appropriate management access As a RS, I need Alice to establish credentials (pub key), so that I can trust externally asserted policy was issued with Alice AS a RS, I need to trust delegations signed by Alice's key, so that Alice can allow Bob (other keys...) or <<claims gathering condition>> to access her resources As a RS, I may delegate resource management user experience, so that I can focus of my core service to the RO As an RS, I need to know which AS(s) Alice wants to use, in order to delegate access control (uma core) As an AS, I want to delegate RqP identification to a UMA Wallet, so that - a RqP can choose their private key and consent management provider - I can avoid directly holding or seeing a users personal details Best, - Alec

1 1

Agenda for UMA telecon 2021-07-01
by Alec Laws 30 Jun '21

30 Jun '21

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-01 UMA telecon 2021-07-01Date and Time - *Alternate-week Thursdays 10:00am PT* - Screenshare and dial-in: https://global.gotomeeting.com/join/485071053 <https://www.google.com/url?q=https://global.gotomeeting.com/join/485071053&…> - United States: +1 (224) 501-3316, Access Code: 485-071-053 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Approve minutes of UMA telecon 2021-06-10 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-10> , UMA telecon 2021-06-17 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-17> , UMA telecon 2021-06-24 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-24> - Relationship Manager - user stories - UMA Interop Testing - AOB

1 0

Draft Minutes of UMA telecon 2021-06-24
by Alec Laws 24 Jun '21

24 Jun '21

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-24 MinutesRoll call Quorum was NOT reached. Approve minutes - Approve minutes of UMA telecon 2021-06-10 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-10> , UMA telecon 2021-06-17 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-17> Deferred Relationship Manager - user stories From: https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-11-19 As RqP Bob, I want to be able to request access to a set of Alice's resources directly from Alice's AS without knowledge of their location, because I don't have to bother getting or caring about all the locations from Alice first. - this one was more related to resource definitions - not resource manager - Alice can give discovery handle (uri to resource), or since Alice's stuff may be in many places, Bob can discover all of the location's by Alice only sharing the AS (as the discover function) - SAML 1.0 only have IDP initiated SSO, then expanded to other use-cases eg SP initiated SSO. UMA so far has deferred discovery, however this brings it back into the scope - it's not hard to be told which RS, eg registered the resource_location with the resource - there are potential security/privacy concerns with this approach - Is the client request bounded to a specific RO from the offset. - Client says to AS, "im looking for these types of resources (types/definitions/indicators) with these scopes" ie by using a UMA Fedz Permission endpoint exposed to the Client - AS returns a UMA ticket and can continue through UMA grant (pushed/interactive claims) - What granularity is the Client/RqP making this initial request for resources? Over resource descriptions: resource type + scopes - *There are major implications for the token response to the Client: token_type, multiple access tokens, including the resource_location + type* - Previously only one Resource Server is ever granted (maybe over many specific resources), however this requires only 1 token - want to maintain the resource server constrained access tokens - another option is we token response in maintained, and the client makes multiple token requests (eg with the PCT) and the specific resource type/indicator - PCT fits within current UMA model since the PCT allows the client to get new access tokens for other RSs without having to go through claims gathering again - This may also enable the RS to register as a resource type provider, is there a way that no specific resources need to be registered at the AS, and that Alice's "ID" is what's conveys back to the RS - fits when paths/uris at the RS are not specific (eg /me/profile vs /alice/profile) - gets back into the relationship manager profile, where Alice pushes RS known sub to the AS which can be returned to the RS through introspection (or the RPT) { "access_token":"sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv", "token_type":"Bearer", "resource_type" : "http://resourcetyperegistry.com/a/resource/type" <- this is the contract with the client over what the response from the RS will be "resource_location" : "http://thisspecificrs.com/path/to/resource" } // this is a non-conforming to oauth2 as the access_token isn't a string { "access_tokens":[ {bearer access token with resource location} ] "token_type":"Multi" } As client C used by RqP Bob, want to be able to request access to a set of Alice's resources directly from Alice's AS on Bob's behalf without knowledge of their location, because I(client) don't have to retrieve the locations first. - the client doesn't have to collect a resource location from Bob before starting the flow, can have a direct relationship with the AS — From: https://groups.google.com/g/kantara-initiative-uma-wg/c/f0g98sr22Rw/m/M5jK9… As a RO, I want to manage my resources independently of each individual RS (UMA core prop) - Alice has resources at many resource servers - In an ideal UMA world, Alice is able to choose her authorization server, and all clients are able to dynamically interact with it. Another case is that the Authorization Server is run for Alice and registers a specific set of clients. Therefore, Alice/Bob may need to interact with multiple authorization servers in order to use the clients they want to. - could we look at the business persons vs user personas - eg the RS operators doesn't trust certain - in the bowtie, the RS has 'no-trust' with the client, however this means it needs trust in some TTP - this is still an excellent goal, however it requires the RS to have direct vetting/relationships with all clients. The RS may have accumulated the resources during some other business purpose and never intended to become an Authorization Server also. - As the custodian, the RS has the most liability in disclosing the resource As an AS(RS) operator, I need statically registered clients (clients + RSs), in order to meet my federation assurance requirements As an RS operator, I don't want to trust any RO chosen AS, because I need strong federation assurance (I can't trust a individual person) As an RS operator, I want to register resources with specific trusted AS, in order to meet my federation assurance As an RS operator, I want to delegate RP registration and authorization, as I never intended to take on this responsibility/cost federation issuance is short-hand for trust framework, legal/regulatory/compliance requirements (I can't trust anyone) These necessarily narrow the ecosystem, UMA+these drafts aim to widens the ecosystem again and remove the need to 1-1 agreements between all parties. - AS holds the agreements with the Client and RS, no Client<>RS agreements is required ('no-trust') - Where does the RO fit into this agreement system? We want to allow the RO to experience agency as they participate in this ecosystem - Can we describe the resulting trust model in GDPR terms. - How does this fit the ANCR receipt, consent token/grant type seems forced? - Is a consent receipt from the client a required claims for presentation? - The client is the one that Alice's information is disclosed to, seems like it(the client) needs to be the one providing Alice a receipt of this (with the contact information etc) Alec will attempt to organize these use cases into a document for solicitation. We need to get less technical and more business/legal feedback on these goals As an AS, I want to decouple the consent management UX from the authorization services, - less required, but motivates the relationship manager client As a RO, I need a personally controlled user-agent (UMA Wallet) to manage my key material, in order to maintain personal-agency in ecosystems As a RO, I want to authorize a "UMA Wallet" to manage RS resources, so that I have a single view into my available RS's and Resources As a RS, I need Alice to authenticate in order to determine which resources she can manage, in order to ensure appropriate management access As a RS, I need Alice to establish credentials (pub key), so that I can trust externally asserted policy was issued with Alice AS a RS, I need to trust delegations signed by Alice's key, so that Alice can allow Bob (other keys...) or <<claims gathering condition>> to access her resources As a RS, I may delegate resource management user experience, so that I can focus of my core service to the RO As an RS, I need to know which AS(s) Alice wants to use, in order to delegate access control (uma core) As an AS, I want to delegate RqP identification to a UMA Wallet, so that - a RqP can choose their private key and consent management provider - I can avoid directly holding or seeing a users personal details New term "*BOLTS*" - Business - operational - legal - technical - social UMA Interop Testing AOB Attendees As of October 26, 2020, quorum <http://kantarainitiative.org/confluence/display/uma/Participant+Roster> is 5 of 9. (Michael, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve, Steve) Voting: 1. Eve 2. Steve 3. Alec Non-voting participants: 1. Nancy 2. Tim Regrets: 1. Domenico

1 0

Agenda for UMA telecon 2021-06-24
by Alec Laws 23 Jun '21

23 Jun '21

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-24 UMA telecon 2021-06-24Date and Time - *Primary-week Thursdays 6:30am PT* - Screenshare and dial-in: https://global.gotomeeting.com/join/485071053 <https://www.google.com/url?q=https://global.gotomeeting.com/join/485071053&…> - United States: +1 (224) 501-3316, Access Code: 485-071-053 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Approve minutes of UMA telecon 2021-06-10 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-10> , UMA telecon 2021-06-17 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-17> - Relationship Manager - user stories - UMA Interop Testing - AOB

1 0

Agenda for UMA telecon 2021-06-17
by Alec Laws 16 Jun '21

16 Jun '21

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-17 UMA telecon 2021-06-17Date and Time - *Alternate-week Thursdays 10:00am PT* - Screenshare and dial-in: https://global.gotomeeting.com/join/485071053 <https://www.google.com/url?q=https://global.gotomeeting.com/join/485071053&…> - United States: +1 (224) 501-3316, Access Code: 485-071-053 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Approve minutes of UMA telecon 2021-06-10 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-10> - Relationship Manager - draft with credentials - AOB

1 0

Fwd: [KI-LC] Wednesday June 16 2021 - FIRE WG presenting
by Alec Laws 14 Jun '21

14 Jun '21

From: Andrew Hughes <andrewhughes3000(a)gmail.com> Date: Mon, Jun 14, 2021 at 11:37 AM Subject: [KI-LC] Wednesday June 16 2021 - FIRE WG presenting To: Kantara Leadership Council <lc(a)kantarainitiative.org> Hi everyone - this month, Jim Kragh and Tom Jones of the FIRE WG will be talking about recent work on the Trust Registry and how this work is being introduced to various organizations. Please forward this note to your WG/DG - The call is open to all. The call is 9am Pacific / noon Eastern on Wednesday June 16 2021. We use the first 30 minutes for invited presentations and follow with a 60 minute LC business call. Call details: *Leadership Council * https://global.gotomeeting.com/join/112012805 <https://www.google.com/url?q=https://global.gotomeeting.com/join/112012805&…> You can also dial in using your phone. United States: +1 (646) 749-3129 Access Code: 112-012-805 *Andrew Hughes *CISM CISSP *In Turn Information Management Consulting* m +1 250.888.9474 5043 Del Monte Ave., Victoria, BC V8Y 1W9 AndrewHughes3000(a)gmail.com *https://www.linkedin.com/in/andrew-hughes-682058a <https://www.linkedin.com/in/andrew-hughes-682058a>* *Digital Identity | International Standards | Information Security * _______________________________________________ LC mailing list LC(a)kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/lc

1 0

Draft minutes of UMA telecon 2021-06-10
by Alec Laws 10 Jun '21

10 Jun '21

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-10 MinutesRoll call Quorum was reached. Approve minutes - Approve minutes of UMA telecon 2021-04-22 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-04-22> , UMA telecon 2021-04-29 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-04-29> , UMA telecon 2021-05-06 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-06> , UMA telecon 2021-05-13 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-13> , UMA telecon 2021-05-20 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-20> , UMA telecon 2021-05-27 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-27> , UMA telecon 2021-06-03 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-03> Eve moves to approve. Steve seconds. Motion Passes! Charter Refresh (vote) Please review the Draft Charter 2021 <https://kantarainitiative.org/confluence/display/uma/Draft+Charter+2021>, changes have been highlighted in red. Steve moves to approve the Draft Charter 2021 document as the new group Charter. Thomas seconds. Motion Passes! (Alec will update the draft and inform the leader council after the call) Group Leadership (review nominations, vote) Eve moves to nominate Alec for Chair Alec moves to nominate Steve for Vice-Chair Hearing no objection. Passes by Acclamation! The group would like to thank Eve for her unwavering support of the group and role as Chair over these many years! Identiverse Coming-up Soon Will any one be there "in-person"? Steve will there if anyone would like to join him There will be a few virtual attendees Colin in moderating a mDL panel, and participated in a CAIRN Alliance panel. Kantara will have a general presentation available. Sal has a pre-recorded session on facial recognition. Relationship Manager - draft with credentials # UMA Resource Server Management This document extends [UMA Fedz] in order to specify the interface provided by the RS to the RO for resource management. This is achieved by introducing a Resource Management API which is used by a Resource Manager Client to view available resources and direct the AS to use for protection. ** This API could also allows the RO to - view access history - set direct policy (ie Adrian clause) - establish credentials required in AS, (smarthealth.card) Reqs: - The RO must authenticate to the RS, in order to authorize access to this API - (this capability of the RS is implied by UMA) - The RO can see a list of resources available at this RS (either protected or not) - The RO can modify the protection of resources (ie which AS to protect) - The RO can see AS's available for protection - can the RO direct the RS to get a PAT from a new AS? This is tricky depending on how PAT's are issued (ie may require end-user redirection) Possible API Names: - resource management - resource declaration - available resources - resource access management (RAM) This document introduces the following new concepts: - Resource Management API The API presented by the RS to the Resource Manager. This API is OAuth protected - Resource Management Token (RMT) (what scope should this Access Token capture?) "uma_management" - Resource Owner credentials The credentials registered by the resource owner within the resource server - Resource Owner Token (or Policies "the VC/VP") A token signed using the resource owner credentials. Allows the resource server to independently verify the the resource owner's intention - Policy Management API The API presented by the AS to the Resource Manager. This API is OAuth protected - Policy Management Token (PMT) (what scope should this Access Token capture?) "uma_policy" - would also be great if during UMA Grant, the AS could send the RqP to their Relationship Manager in order for new policy to be created 'just in time' (ciba-ish...) - this has been the 'cascading AS' discussion is past. RM provides a OIDC interface to facilitate the redirect (could be SIOP now?) ### 1.3 HTTP Usage, API Security, and Identity Context - add link between RM API and RM Token informative The use of the `uma_management` scope when requesting a RMT may indicate to the RS's authorization server that establishment of one or more PATs with an available UMA AS is 'useful' #### The `Resource Management API` allows the Resource Owner to: - View the available resources hosted at this RS, and their current protection - Register a Resource Owner Credential - (eg dyn client registration, posting a DID) - (for discussion) have verifiable credentials issued by the RS to the RO - not strictly necessary since the ROT can be created by the resource owner - This is a good outcome, since the burden on the RP is moved to the RO. The RO can present/delegate these VC's further - Should this draft specify the framework or the specific tech (oauth client vs w3c) and further profiling of the technical (similar to the uma grant claims types) - ~View the UMA Authorization Servers available to be used to protect~ - ~Manage the UMA protection of available resources~ Starting Conditions RMA: - The RS hosts resources for the RO - The RS supports resource protection from an UMA AS - The RS has a UMA PAT at one or more UMA ASs - **for discussion**A RS that support this profile does not need resource owner specific PATs. If the ROT is embedded in the RPT, no PAT or introspection is even required. One RS level PAT to allow introspection, and opaque RPTs to be issued - are situations where the RS doens't even know/trust the AS too far? No? - the RS implicitly trusts the AS since it includes the authority of the RO, outcome is RO can use any ASs, moves challenges for having an AS per RO Step 0 The Resource Manager obtains an OAuth Access Token valid for use at the Resource API. The Access Token must allow the RS to determine the RO's resources. - is there a purpose for NOT the RO to use this interface? Is this 'delegation' too early in - *trying to stay away from defining the identity system. - not necessary to identify the person, instead the RS needs to know the rights over the resources Step 1 (Get Info) The RM obtains a list of available resources Step 2 (Manage Credential) The RM registers credentials with the RO - Viewing and modifying registered credentials - Registering a new credential Step 3 (Optional?) The RM requests resources to be issued as Verifiable Credentials against one of the registered resource owner credentials - this would use something akin to https:// mattrglobal.github.io/oidc-client-bound-assertions-spec/ RM->RS: POST /give-me-a-crednetial-for { my_credential(step2), the resource(step1) } -> issued VC Ending Conditions RMA: - The RM has a list of available resources for the RO at this RS - maybe, the RM has w3c VC's representing the resources - The RS has attached the ROC(s) to the user account (public part / shared secret ) - The RM has the RO credentials (private part / shared secret ) #### The `Policy Management API ` allows the Resource Owner(or resource rights administrator??) to: - (is this the general resource rights administrator?) doens't need to be the same as the RO if there has been some RO->RRA delegation in the background - view existing policies for them - create new policies for resources (registered or not?) Starting Conditions PMA: - the RMA start and end conditions - The AS supports the policy management for the Step 0 The Resource Manager obtains an OAuth Access Token valid for use at the Policy API. The Access Token must allow the AS to determine the User(RO/RqP)'s policy. Step 1 (Get Info) The RM obtains a list of their existing policies and the AS supported policy claims Step 2 (Create Policy) The RM uses a ROC + resource description + support policy to create the resource owner token. The ROT is registered at the AS #### ## The Resource Owner Token ( Verifiable Credential or Presentation ) resource owner credential has two part: a identifier and the actual credential (oauth client id and oauth client secret) (did + private key) ``` ROT = a JWT signed by the ROC { id: rm create policy id? resource_owner_id : identifier portion of the ROC resources: [ resource_server: resource_id: (similar to how the path identifies the RO to the RS) resource_location: ?? allowed_scope: [ out of the available scopes ] ] allowed_rqp: client_id, other claims { email: bob(a)email.com } } ``` ## Available Resources Endpoint (RS) The API available at the available resources endpoint enables the resource manager to have knowledge of the resources hosted by the resource server for the resource owner. \_rs_id is a resource server defined identifier for a resource. Before a resource is registered at an AS, there is no handle/reference available (unless the RS provides one) GET /my-resources/ ``` [ { "_resource_id" "ABC", "resource_scopes":[ "view", "http://photoz.example.com/dev/scopes/print" ], "description":"Collection of digital photographs", "icon_uri":"http://www.example.com/icons/flower.png", "name":"Photo Album", "type":"http://www.example.com/rsrcs/photoalbum", // uri/location of the resource? }, ] ``` Protected Resources ``` [ { "_resource_id" "ABC", "authorization_sever_resource_id" : "_as_id" "authorization_server" : "as_identifier", "registered_scopes" : [ "view" ] }, { "_resource_id" "ABC", "authorization_sever_resource_id" : "_as_id_2" "authorization_server" : "as_identifier_2", "registered_scopes" : [ "view", " http://photoz.example.com/dev/scopes/print" ] } ] ``` In dashboard world, rs_id = PeI (pension identifier) - to confirm, is the PeI the same as the as_id? ie is it created by the RS or the AS RS_1 holds pension A with identifier a RS_1 registers pension A single person, single resource, single rs: can have multiple resource registration, eg with different scopes Resource = Patient Registered Resource 1: Just the Patient Object Registered Resource 2: The Patient + Sub Objects ### Available Resource Description A registered resource is a JSON document that extends the resource description from [UMA Fedz 3.1 Resource Description](1) with the following parameters: authorization_server OPTIONAL A string identifying the authorization server that protects this resource ** could also be the AS policy uri from resource registration? (1 https:// docs.kantarainitiative.org/uma/wg/rec-oauth-uma-federated-authz-2.0.html#re… ) #### List Available Resource Descriptions #### Update Available Resources Description ## Resource Owner Credentials Endpoint (RS) This API available at the Resource Owner Credentials Endpoint enables the resource manager to view and manage credentials registered for the resource owner. GET /my-credentials ``` [ { _id: cred_id, cred_type: did | client cred_value: { <a did > ...or <oauth_client metadata> } } ] ``` ## Resource Owner Policy Endpoint This API available at the Resource Owner Policy Endpoint enables the resource manager to view and manager policy registered for the authorized user ## [UMA Fedz] 5. Token Introspection Endpoint - needs modification to include the ROT, either to replace a permission, or an an 'authority' within a specific permission (to be bw compatible) ``` HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store ... { "active":true, "exp":1256953732, "iat":1256912345, "permissions":[ { "resource_id":"112210f47de98100", "resource_scopes":[ "view", "http://photoz.example.com/dev/actions/print" ], "exp":1256953732, "authority": ROT.JWT.VALUE } ] } ``` ## [UMA Grant] 3.3.4 Authorization Assessment and Results Determination - describe set math changes - ANCR receipt could be used on first contact with the AS (from the RM). Establishes the initial terms of this relationship and the delegation of authority - (Anchor Notice & Consent Receipt is a extension of the Consent Receipt (CR 1.2.1), including how it fits into protocol flows) Next steps: - defines the change to the AS authorization assessment - AS → RM. "i don't have a policy right now, maybe you RqP can create one that fulfills this clients request" - into ideas of a RO/RqP relationship manager (aka Wallet) AOB Attendees As of October 26, 2020, quorum <http://kantarainitiative.org/confluence/display/uma/Participant+Roster> is 5 of 9. (Michael, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve, Steve) Voting: 1. Eve 2. Michael 3. Alec 4. Domenico 5. Thomas 6. Steve 7. Sal Non-voting participants: 1. Scott 2. Colin

1 0

Nominations for 2021 Chair & Vice-Chair
by Alec Laws 08 Jun '21

08 Jun '21

Hi all, Couple items for the groups attention 1. We're meant to renew the Chair and Vice-Chair roles on a yearly basis. As per Eve's latest update, she's not able to continue in her role as Chair. *Please respond with your interest or nominations for these roles*. I'm more than happy to continue in as chair/vice-chair for this upcoming year 2. If you haven't already, please review the proposed draft Charter [link <https://kantarainitiative.org/confluence/display/uma/Draft+Charter+2021>] and reply with any further comments Best, - Alec

1 0

Agenda for UMA telecon 2021-06-10
by Alec Laws 08 Jun '21

08 Jun '21

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-10 Date and Time - *Primary-week Thursdays 6:30am PT* - Screenshare and dial-in: https://global.gotomeeting.com/join/485071053 <https://www.google.com/url?q=https://global.gotomeeting.com/join/485071053&…> - United States: +1 (224) 501-3316, Access Code: 485-071-053 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Approve minutes of UMA telecon 2021-04-22 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-04-22> , UMA telecon 2021-04-29 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-04-29> , UMA telecon 2021-05-06 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-06> , UMA telecon 2021-05-13 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-13> , UMA telecon 2021-05-20 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-20> , UMA telecon 2021-05-27 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-27> , UMA telecon 2021-06-03 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-03> - Charter Refresh (tentative vote) - Group Leadership (review nominations, tentative vote) - Relationship Manager - draft with credentials - AOB

1 0

Draft minutes of UMA telecon 2021-06-03
by Alec Laws 03 Jun '21

03 Jun '21

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-03 MinutesRoll call Quorum was reached. Approve minutes - Approve minutes of UMA telecon 2021-04-22 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-04-22> , UMA telecon 2021-04-29 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-04-29> , UMA telecon 2021-05-06 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-06> , UMA telecon 2021-05-13 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-13> , UMA telecon 2021-05-20 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-20> , UMA telecon 2021-05-27 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-27> Deferred Charter Review/Refresh Please review the Draft Charter 2021 <https://kantarainitiative.org/confluence/display/uma/Draft+Charter+2021>, changes have been highlighted in red. (5) - A horizontal UMA security profile, considering other profiles including HEART, FAPI, and OAuth 2.1 Changes to Group Leadership - we need to renew our annual voting roles, Chair and Vice-Chair - Next quorum we'll need to discuss and ideally vote on this topic - *Feel free to send nominations to the list* so we're prepared at our next quorum. Alec will send a separate note to the list to raise this request - If you have a voting membership, please let Alec know if you can/can't attend next week Relationship Manager The last session was recorded, check it out so these will make sense Discussed the merits of having a credential (public key) registered at the RS for a Resource Owner, and the different use-cases it starts to enable, both for UMA and getting into VC/SSI. - RO can sign policy it writes to the AS. The RS can have less trust in the AS since it's really trusting the RO - Today the RS trusts the AS as the RO. With the credential, the RS can trust *any* AS - Give the RO some more fiduciary capability aside from system-system (RS-AS) trust. This is part of Decentralized ID value prop - RO can delegate directly to other RqPs - Can this help the RS, not have to trust the RO as much? ANCR established the RO establish terms with any other system - Binding is the most critical bit of the trust flow. CIBA also solves for this, in a way that a RqP - UMA helps Alice ensure, that Bob is who he says, such that her policy can be applied to his request for Access - CIBA helps Bob ensure Alice is who she is. Currently we don't strongly bind Alice to the AS - Can we bind Alice to the AS, in a way the requesting party can confirm who she is? - ANCR wants to capture all this trusted state so that all parties can have this transparency, including getting Witnesses just in time. (parallels to a KERI witnesses, there is cryptogrpahic binding + attestation over an identifier) - ie UMA pushed claims, where the AS can 'ask for more' from a trusted third party (the Witness) - RS can issue to Alice, VCs. Either resource's as a VC, or actually data-containing VCs. Alice is then free to delegate and use from there. (The ssi credential exchange api) RS <strong trust> RO <> AS RS <> AS <> RqP <> RPT{Alice's proof} <> RS Alec will update the last RM Draft to: - Add back the credential, drop Authorization Servers API from it. - We're shifting the trust from the Fedz Auth api to the RO through their credential. AOB - will be looking to setup an ANCR presentation to the Group is around a month. Sal will let us know when he's ready Attendees As of October 26, 2020, quorum <http://kantarainitiative.org/confluence/display/uma/Participant+Roster> is 5 of 9. (Michael, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve, Steve) Voting: 1. Michael 2. Steve 3. Eve 4. Alec 5. Sal 6. Domenico Non-voting participants: 1. Scott 2. Colin Regrets:

1 0