Meeting minutes
<bumblefudge> should we self-introduce on irc?
[slide 3]
[slide 4]
[slide 5]
[slide 6]
[slide 7]
[slide 8]
[slide 9]
simone: The user (holder) only needs to trust the browser and wallet.
[slide 10]
[slide 11]
[slide 12]
[slide 13]
[slide 14]
[slide 15]
[slide 20]
<bumblefudge> threat modeling document not open on gdocs
<bumblefudge> or rather, the credentials i'm presenting aren't enough to see it :D
rbyers: Let's discuss perpetuating sharing of data by making an API available.
… Today with the EUDI wallet when using a custom scheme it goes directly to the wallet, while the browser API goes through extra screens.
… So the browser API has greater friction. Does that make it less available?
<bumblefudge> for the scribe
<bumblefudge> that's anthony nadalin
<bumblefudge> WICG/
<bumblefudge> ^ tried adding this to the slides as a definition of Jevon's Paradox but its permissions are locked down
Tony: You might trust the custom scheme more than the browser because the API is more opaque to it.
rbyers: The question here is whether the browser here to be the user's agent (protecting user privacy) or is it a threat actor (potentially mining user data)?
… That's a reasonable perspective but I disagree.
Muhammad, is an API or custom scheme easier for the developers?
rbyers: I don't think choice of tech will influence adoption, except for interoperability.
Tony: Browsers may deprecate or block specific custom URI schemes.
rbyers: Chrome's latest position is that it will not block custom URI schemes, but may introduce speedbumps.
… We were concerned about malicious web sites reaching out to wallets via custom schemes
… I believe Firefox has gone on the record that they may block.
Tony: There are issues both ways.
<Zakim> bumblefudge, you wanted to talk about framing concepts
bumblefudge, It feels like we've jumped ahead to assuming that a browser API is how all credentials will be passed.
… which formats are used needs to be part of the conversation
… the threat model should consider the non-technical threats of allowing credentials to be passed anywhere that browsers are installed
… more or less browser friction doesn't solve the legal problem, the Jevon's Paradox problem
simone: The objective of the threat model is to understand the global threats
… Also to understand the requirements, what are the privacy and security properties we need to protect
<bumblefudge> aram: evaluative methods !== solving underlying problems, it's encouraging implementers to own their role in the rollout of technology in society
kdenhartog: We see that there are 2nd order effects that come into play when bringing in an API.
<bumblefudge> governments LOVE evaluative methods to tell them which levers and cudgels are worth reaching for
kdenhartog: This ossifies the way that it should be done.
… E.g. we've seen issues trying to take out cookies
… How we're going to pass credentials in the browser defines and ossifies how we're going to share credentials.
<bumblefudge> *simone we also need comment rights here: https://
simone: What can we do on different levels?
… (Asks the audience.)
kdenhartog: We posit that this tech has been worked on for quite a long time and we wanted adoption when working in this space.
… It wasn't until we left this space that there were social implications that come into play.
… We've been able to limit the extent of the technology by limiting adoption.
… Let this technology continue to grow on its own.
… Once we have an understanding of the threat model, let it ossify.
… Wait and see. Don't ossify now.
… Why are we certain that this is the correct time to design, when we haven't seen it adopted.
Tony: mDL has an API, the goal of ISO was to find a more supported way of getting things out of the wallet
… The interface is very specific about what you can get out of the wallet.
simone: While we wait... what can we do?
… What would you (kdenhartog) like to see while we are waiting?
kdenhartog: We just wait. Is this the right time to move fast and break things?
… We shouldn't be moving fast. Move slow and figure out the right answer.
… If browser APIs are a form of ossification (like cookies) we shouldn't be moving fast.
simone: If I just wait, there might be a worse situation. While we wait, what should we be doing?
kdenhartog: As a browser, do nothing. For people in this space, iterate at the app level.
rbyers: I previously agreed, but governments moved to advance this tech, we risk missing the boat because it was ossifying already.
… Do we let it ossify, or engage now to try to improve it.
… It's more responsible to accept that it is happening and engage.
… Google will not legally be allowed to ignore it.
… If we do nothing now, the W3C will be too late to do anything at all.
<Zakim> dezell, you wanted to comment on mDL
dezell: I represent the convenience store industry. We've had to engage in age checking requirements.
… Rejected mDL in the past, preferred Verifiable Credentials as it does not infect a data set
GregB: I come from VC perspective (application layer from your perspective).
… We're happy to help here and are working on new crypto standards for unlinkability.
GregB: We can help on these issues.
Pam: I'm glad we're having this conversation.
… Ossification of de-facto vs. an intentional design
John_Bradley: Speaking with my EUID wallet provider hat on.
… The research and education community has been building its own wallet.
… We are concerned that QR code system introduces security vulns
… Working on better cross device
… Also concerned about a JS API that only supported mdocs
… People are involved in our project because they want to see a more privacy-preserving option
… If we do nothing, 40% of the ecosystem will have an mdocs-only API
… There are a lot of things stopping us from delivering perfect solutions on day 1.
… European Commission at least wants a unified solution for age verification.
… How do we direct some of the energy happening in the government space in a better direction.
Tony: There is already an mdoc browser API.
… It doesn't solve cross-device.
… ISO is looking for a browser API to solve that, but it opens up some different problems.
kdenhartog: To use FedCM as an example, OpenID has existed for a long time and now is the point where a browser API is coming into play.
kdenhartog: If the goal is interoperability that is speeding up adoption and Jevon's Paradox.
… We can make some decisions, like we've done in FedCM, but we're forcing decisions now.
… We're going to determine the proper way of doing it by setting a browser API
… mDLs haven't succeeded yet, so there isn't a good app-level design to turn into a browser API
<Zakim> bumblefudge, you wanted to push back on "decentralized versus federated" model a little
bumblefudge: We shouldn't spend too much time on the speed up/down decision.
… All the formats being compared here have different decentralization properties.
… All of these layers aren't three-party models.
… All of this has consequences for governments and regulators.
… The evaluative questions matter as much as the threat model.
… How you right an evaluative document can have more influence than API good/bad.
… Most important work is to evaluate the impact of the formats.
… Governments would love that input from technical experts.
AramZS: It seems like there will be an increasing number of entities who feel they have to consume these credentials.
… Consider whether consumers won't want to consume all the data in these credentials.
… Then on the other hand consumers who want data that we don't want them to consume.
… I don't want people to have to present their driver's license to prove they're human.