UMA telecon 2020-06-11

Date and Time

Alternate Thursdays 6:30am 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://kantara.atlassian.net/wiki/display/uma/Calendar

Agenda

Approve minutes of UMA telecon 2020-03-12, 2020-03-26, 2020-04-02, 2020-04-23, 2020-04-30, 2020-05-14, 2020-05-28
Profiling work
- Resource definition profile spec status
- Wallet profile
Conformance work
AOB

Minutes

Roll call

Quorum was reached.

Approve minutes

Approve minutes of UMA telecon 2020-03-12, 2020-03-26, 2020-04-02, 2020-04-23, 2020-04-30, 2020-05-14, 2020-05-28

MOTION: Sal moves: Approve minutes of UMA telecon 2020-03-12, 2020-03-26, 2020-04-02, 2020-04-23, 2020-04-30, 2020-05-14, 2020-05-28. APPROVED by acclamation.

Profiling work

Resource definition profile spec status

Alec has been looking at PAR for some inspiration and considering the access token vs. ticket question. Eve offered encouragement to publish a "drafty" draft with holes in it. People can suggest how to fill them in. Examples of old revs of IETF RFCs will show "TODO" items and such. Colin points to a Kantara Word template for specs, and can send a Markdown version to Alec as well.

Wallet profile

Let's walk through the wallet-sequence.png diagram that is attached to the 2020-05-28 minutes. This puts UMA FedAuthz in scope a little bit. The Wallet is a new client type that is about, roughly, policy administration. It's a third client type, aside from the UMA Client and the UMA Resource Service, that both Alice and Bob would have one of. This diagram shows Bob using his Wallet.

Eve showed our Legal Role Definitions slides and the spaghetti diagram, where the RqP has an interest in "permitting" the RO's AS to know their claims and "delegating" the authority to seek access to the client that they use.

We recommend putting the RqP and the wallet next to each other in the diagram because the wallet is the RqP's choice. Alec has been advocating that the AS be a kind of community resource that both an RqP and a (potentially different, distinct) RO might share.

Previously Alec had called the wallet component a "personal AS" and also an "agent". It turns out that using "personal AS" isn't as helpful as we thought because it seems to imply that the RqP role needs (or can specially benefit from) a different AS than the one that the RO uses. But Adrian's (and Alec's) advocacy for a sort of community AS shows that there is no special benefit here. Note that there might be a "Bob wallet" and an "Alice wallet" in any one deployment picture.

This profile is intended to mitigate the privacy consideration risk that is identified in UMA Grant Sec 6.2, "Requesting Party Information at the Authorization Server". Alec saw that consideration and decided not to implement PCTs. That consideration is basically saying, "Do the right thing in the case of having to deal with IAM personal data risks." The alternative that this profile is intended to make possible is that the AS is able to persist only what an SSI verifier would need to persist in the case of handling VCs. Is that anything at all, or nothing?

eIDAS has been listing, and Anil John has been working on, "universal verifiers". What does that mean?

Conformance testing project update

Eve was unfortunately too slammed to make progress on this!

Scheduling and chairing help

Should we consider going to a weekly schedule to make faster progress?

Eve could use some help with running meetings.

Attendees

As of 17 Feb 2020, quorum is 5 of 8. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike)

Peter
Sal
Thomas
Maciej
Eve
Mike

Non-voting participants:

George
Adrian
Anik
Alec
Nancy
Lisa
Colin
Tim

Browser not supported