UMA telecon 2021-04-29

Date and Time

Primary-week 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 2021-04-22
IIW Review and Thoughts
Profiles Discussion, relationship manager draft
AOB

Minutes

Roll call

Quorum was NOT reached.

Approve minutes

Approve minutes of UMA telecon 2021-04-22

Deferred

Pension Dashboard Update

Under resources, the PDP profile and license are up. There will be some fine tuning over the coming days

https://kantarainitiative.org/uma-profile-for-uk-pensions-dashboard-programme/

IIW Review and Thoughts

Huge focus on DIDs and SSI. They're is a lot of ssi community discussion to move past the issues as they arise eg the growing number of DID methods. Discussions are starting to move up the stack towards the user.

OAuth focused solutions are being used in practice to solve real-world problems. Helps to explain why there is less discussion on these topic vs DID/SSI. There seem to be some other forums for ietf/oauth vs at IIW.

The focus on mobile apps will hinder the SSI, there is some new efforts to standardize HTTP based API, a lot of current projects use web based keys systems (did:web & did:peer).

The focus on wallet/user controlled software is good from privacy perspective, but pushes a lot of liability to the user. The chain of trusted systems is broken if wallets aren't assured as part of this chain (from issues→verifier, or OP→RP).

The discussion is very low building block levels around the control of identifiers. There is a shift from blockchain only solution to more witness based key rotation/control (KERI).

At TOIP, Mark has been working on a privacy controller credentials to define how parties who receive information must give the user a record of having their data(?). The 'accountable person' from a gdpr perspective is often not the subject/company, but some other party eg a lawyer/law firm.

Interesting to see if browser vendors start to pay attention if they can put wallets in the browser. This would seriously improve adoption and make it easy for people. Sal notes there is a push to this, trying to make it a clear request. Firefox has a concept of 'personas' ~5years ago. The DHS SVIP was based around a browser extensions functionality (CHAPI). Microsoft has all the pieces to do this (vested interests in DID, and they own a browser). For privacy, browsers have been pushing against tracking + RP collusions (eg restrictions on third party cookies.) We need notice + transparency before transactions occur, similar to how OAuth works today (show notice and user has choice before sharing). A lot of current high assurance requirements mean browsers cannot see any of the credentials/PII, and increase the desired collusion between parties (everyone is well well known)

Reliance on Browsers/mobile OS risk "centralizing" or restricting the options, against the agency principles of SSI. Receipts can remove dependencies and provide interop between wallets. There are ways to use a receipt to show provenance to get a new credential issued. In this context a receipt isa credential, it can be a VC if it needs some of those functions. How do zero knowledge proofs affect these discussions, change the surveillance possible. ZKP is part of the challenges with the many DID methods, the DID methods tends to define ZKP functionality of identifiers/keys which changes/removes the interoperability of the VC objects. ZKP needs to be understood by the verifier

Are notice specifications a type of data provenance for a VC? Data provenance - when was it collected, constraints, purpose of use... Data sharing is system to system, however notice is inherently something for a human person. Today, user/person has little ability to assert the use of their data, this is something that must be added/built into a platform. A notice resulting in a receipt allows a person to communicate with the data controller and assert their rights as agreed upon. A physical receipt establishes the trust that the merchant won't take more than the printed amount.

Want to separate rights from services, people need support manage their identities and private keys, and that's why account services exist.

The decentralized goal is somewhat of a red-herring, the vast majority of people want and need support to manage this technology. There will be some people (eg cryptocurrency community) however if this technology is entirely hidden, it ends up being a different technical mechanism for providers to hide from the person. If there is some transparency/portability out of the box maybe this is the person value, however this hasn't been demonstrated, it's the same as an with current web technologies, there needs to be integration/testing between the domains.

The issues/holder/verify split is logical, in practice all parities end up performs all three roles. This requires additional definition of responsibility/accountability in an ecosystem. OAuth has a clear delineation in this case (OP< RS< RP <RO)

Profiles Discussion, relationship manager draft

AOB

ANCR workshop around adding standard notice/policies, adding governance to open source projects. Goal to drive to interoperable policies

https://github.com/Open-Notice/ANCR-Hack-Worshop-May4th-2021/blob/main/README.md

Attendees

As of October 26, 2020, quorum is 5 of 8. (Michael, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve)

Voting:

Michael
Thomas
Alec
Sal

Non-voting participants:

George
Colin
Nancy
Scott
Mark

Regrets:

Domenico

Browser not supported