UMA telecon 2020-07-16

Date and Time

• Alternate-week Thursdays 10am PT
  • Screenshare and dial-in: https://global.gotomeeting.com/join/485071053

  • United States: +1 (224) 501-3316, Access Code: 485-071-053

  • See UMA calendar for additional details: http://kantarainitiativekantara.atlassian.orgnet/confluencewiki/display/uma/Calendar

Agenda

• Approve minutes of UMA telecon 2020-07-09
• New profiles
  • Resource definition profile
  • Wallet profile
• AOB

...

• Approve minutes of UMA telecon 2020-07-09

Deferred.

New profiles

• Resource definition profile status
• Wallet profile

Continuing with the flows and diagrams in Alec's recent email and spec text in his other recent email and his user stories in his other recent email...Notes are to be added shortly.

Use of the term Wallet can be confusing especially in cross context with SSI - fundamentally it is a client to the RS. Alec will come back with some suggestions to eliminate this confusion. 

Is the Wallet just a user-agent? Alec: no it is a server/service similar to an AS or RS, it is not a Browser/user-agent. Is there a definition of user-agent to help reduce this confusion? The Wallet is a new Client type to the RS and AS

Alec: Alice authenticates to the RS and authorizes the Wallet to use the Manage API. The wallet is a Client to the RS, this client relationship is out of scope. Through the manage api Alice create credentials or key material known the the RS. Adrian: is that necessary? Alice already has a credential to the RS. The RS should trust any policy signed by the AS, without needing new credentials. Alec: Sure, want to keep the actual mechanism out of scope, however believe this needs to be some kind of key that Alice can use asynchronously to create policy the RS can verify.

The wallet as a client to the AS uses the Policy API to record Alice's intention with the AS. Similar to the RS, how the wallet gets the access token is out of scope. This policy is very similar to the permission API since it includes resource ids and scope, it also includes information about required claims gathering from Bob to use the resource. Adrian: the policy should include the triplet or what is being access, what are the claims requirements for Bob and what is the intended purpose for use. Alec: how would intention work, is it predefined value or free form entry by Alice? Adrian: it would have to be registered somewhere independent of the AS. Alec: agree intention is important, can purpose or intention be captured through claims or scopes? Deferred discussion for later

Adrian, In the diagram (from draft spec text email) the wallet should be split so that there is one wallet is used by Alice is UMA phase one, and a different one is used by Bob during phase 2. Alec: that implies there must be two wallets, but Alice and Bob could use the same service. In the smallest possible case there is one RS, one AS and one W. Adrian, want the diagram to be clear between phase 1 and 2. Alec, should the phase 2 part where Bob uses his wallet to meet Alice's policy be a different extension. This is the 'cascading authorization' part

Points for continued discussion clarification 

1. Clarified that intention of manage and policy control API with ‘wallet’ is scope of profile addition. This is main intention of this spec

2. Cascading AS - needed/why?

3. Relationship between client API and Claims gathering

4. Consider RS first vs AS first

Attendees

As of July 8, 2020, quorum is 6 of 10. (Michael, Domenico, Peter, Sal, Gaurav, Thomas, Andi, Maciej, Eve, Mike)

...