Draft minutes of UMA telecon 2021-04-29

29 Apr 2021

      https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-04-29
MinutesRoll call

Quorum was NOT reached.
Approve minutes

   - Approve minutes of UMA telecon 2021-04-22
   https://kantarainitiative.org/confluence/display/uma/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-programm...
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 https://github.com/Open-Notice/ANCR-Hack-Worshop-May4th-2021/blob/main/READM...
Attendees

As of October 26, 2020, quorum
http://kantarainitiative.org/confluence/display/uma/Participant+Roster is
5 of 8. (Michael, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve)

Voting:

   1. Michael
   2. Thomas
   3. Alec
   4. Sal

Non-voting participants:

   1. George
   2. Colin
   3. Nancy
   4. Scott
   5. Mark

Regrets:

   1. Domenico

Alec Laws

Adrian Gropper

Alec L

tags

participants (3)