-
Notifications
You must be signed in to change notification settings - Fork 9
2023 11 29 Meeting Notes
Organizer: Tim Cappalli
Scribe: Lee Campbell / Tim Cappalli
- Administrivia
- Canceling 12/27 call
- Intros from new folks
- Updates from Blink incubation
- Anyone prototyping with their wallet or verifier?
- Discussion: This API should address the Jevons Paradox around increased consumption of verifiable credentials and the rise of their abuses
- Discussion: “protocol” property
- AOB
- Tim Cappalli (Microsoft)
- David Waite (Ping Identity)
- Lee Campbell - Google/Android
- Mike Jones - independent
- Marcos Cáceres - Apple
- Benjamin VanderSloot - Mozilla
- Tobias Looker - MATTR
- Kyle Den Hartog - Brave
- Oliver Terbu - MATTR
- David Zeuthen - Google
- Nick Doty - CDT
Sam: Has open CLs to update the Chrome implementation to match the current proposed API.
Tobias: Has an end to end prototype working. Good UX, addressing some of the problems addressed. Working on Samsung device now.
Tim: Where should people report feedback?
Lee: Github repo or email
Sam: Public engagement is more ideal, e.g. github issue
Tobias: one issue with the matcher, with individual attributes. No credentials being rendered in the selector
Lee: will follow up
Marcos: can you post some sample code? Would be interested in seeing.
Tobias: will try
Sam: majority of the issues arise in this stage (early incubation). For OpenID4VP, directionally correct?
Tobias: prototyping done with mdoc protocol, vs over OpenID4VP. Worked quite well, Similar to syntax in 18015-5. Do you envision having a standard HPKE representation across platforms? Currently android specific.
Lee: prototype you’re using at the moment, opaque request and response. Demo implementation of HPKE. Standard HPKE, just our implementation of it. Should HPKE be at the top level like the Apple folks are proposing. Current proposal written with it at the top.
DavidZ: decided to use what Apple proposed in original mob doc request api
Tobias: implementation is great. Just the packaging of the result.
Discussion: This API should address the Jevons Paradox around increased consumption of verifiable credentials and the rise of their abuses
Kyle: As a resource becomes more available it's consumed more. What will happen if we make credentials more available on the web? We assume that PII will be requested far more often than it is today. As a result this could be harmful to user privacy at scale.
Nick: Will we see over asking for data?
Tim: There are options in the User Agent UX to add more friction and consent screens when asking for sensitive data.
Kyle: Does this belong in the web platform at all or will doing so make it more ubiquitous then if it’s handled at the operating system layer? It seems we all agree we inherently want to cause more friction and limited adoption when use cases aren’t considered useful, but it’s not clear how we delineate that yet. Will oppressive governments write regulations around this, use this to surveil or produce a chilling effect on dissenting views?
Lee: existing patterns exist with custom URL schemes. This is going to go ahead with or without us. Decided it would be better to be in the game and have some influence, have some say in the privacy properties and user experience.
Sam: point you raised is valid and something we’re equally worried about
Tobias: sharing verified data attributes has been around for a while. It’s already here. The role the browser can play is mitigating some of the unintended usages that do harm user privacy
Kyle: some initiatives have failed because the tech has not been available (e.g. UK age proof). By making it available on common platforms, we could be helping it along. What happens with more regulation? Does legitimate use become a steamball and everything suddenly is a legitimate use that’s regulated?
Ben: it’s coming anyway is a bad argument, we need to justify what we do vs the technology will march forward with or without us. That said, if this were to exist, a browser API and making these requests legible so browsers can introduce friction is probably one of the best case scenarios for it. So the UA can take action on behalf of the user.
Nick: if other patterns exist, and we want devs to use this because its better, and we introduce friction for those protections, then will they go back to the old ways without friction?
Lee: we can do stuff to the alternatives, if we have a better solution. If we landed this, and it worked well at scale, there’s options we can do for custom URL schemes (e.g. introduce even more friction than web plat api). If we don’t have a viable alternative, we have a lot harder time making those flows harder to use. If we still see a lot of use on the less ideal ways, UAs can work hard to address.
Kyle: if we move past the philosophical argument and talk about the how, this is where it becomes interesting. How do you determine that dissenting voices aren’t being censored on Twitter or Reddit or that wallets are gatekeeping the web. As we saw with WEI, developers got their pitchforks out for trying to attest to integrity which would be necessary for high assurance credentials and use cases that are regulated by governments. Do we expect web developers won’t have a similar visceral reaction here?
Sam: something we’re equally worried about, but hard to make a projection without seeing it in practice. Intermediating the exchange, does provide UAs the ability to control the deployment. If we see it being used in a way we don’t expect, allows us to try to make a judgement.
Kyle: to that effect, the part that worries me most, once the cats out of the bag, we can’t pull it back in. e.g. facebook in order to recover, you have to provide a phone number, which in many countries requires ID to get a phone number, resulting in deanonymization. Hard to pull all this back which we are seeing with 3rd party cookie deprecation. Good way to frame this may be that when OIDC was created, 3PC were used. Had it been a browser API from day 1, what would have been different? The one thing that is clear, is that it will happen and it seems that doing it as an OS api may induce the friction necessary to limit usage. Can we say the same by making it a web platform API?
Nick: personally not much more confident about the OS deployments. Want to speak to Lee/Sam’s suggestion about there could be protections in place by the browser: I think we should start documenting those things now. We don’t have lots of good examples.
Sam: Pop up windows are a good example. Didn’t require user gestures. Notification API as well.
Tim: WebAuthn attestations are another example
DW: sounds like we’re talking about different privacy risks. Who is responsible for protecting the user? Amplification of requests for real world identity? Governments forcing users?
Nick: those are some of the risks
Sam: Action item could be to enumerate some of these risks. Kyle/Nick?
Kyle: the ones we talked about are the ones I’ve been thinking about so far. What worries me is the one’s we’re not thinking about. For example, I came across a website (https://polycentric.io/) using notifications approval as a way to gate access (e.g. register). This wasn’t designed with this in mind, so we have to carefully consider this with this API and think what’s the adversarial chess match look like to predict how this will be abused. Similarly, it’s just just us technologists who need to do this, but also regulators. Some aren’t even aware, and not thinking about impact. How do make this as responsible as possible? Nick has a decent list going in PING group. I’ll work with Nick to make sure that list gets enumerated as an example.
Lee: there’s also a bigger set of websites that will be mandated to take these identities by governments (ex: EU and US). KYC, primary sign in, payment confirmation. Lots of places this could be mandated. How do they actually want to do that? Current feedback is a standards-based API is desired.
John: European parliament passed legislation for the EU verifiable credential and top sites in the EU need to accept them for authentication. European lens with more privacy centric considerations. Need to make sure the API supports the more sophisticated blocking rules. Tune the level of protection the API can provide by the wallet instance. Wallet may have more metadata, RP certification, etc. Europe has signaled that blinded BBS is what they’re looking, but may take SD-JWT in the interim.
Kyle: notion of privacy in the claims model is somewhat dangerous. Fundamentally the way this works is going to cause problems that none of us can control even with selective disclosure. Our opportunity to say we’re not going to support this, is a strong signal. E.g. country asking for a root ca to be added to browsers. There is power in saying no.
Tobias: Is there an opportunity to do it better than what is done today. Many of the current flows present full documents and therefore don’t have ideal privacy properties. Building this new API could allow us to significantly improve on the status quo.
Sam: Designing the API to support many protocols, but we only know of OpenID4Vp today. Are there other protocols that folks are considering or have any examples of other candidates?
Tim: What is a protocol, what would the vanilla mdoc protocol be called?
Marcos: Need to have an eye to limit these, the more we have the more things to review etc..
Kyle: Useful to design around a single protocol first, is thats OpenID4VP maybe thats ok. Lots of fragmentation in the VC space. e.g do we have to support didcom? Lets pick the ones that have adoption and make sure we can make it extensible if new protocols become heavily adopted.
Marcos: OpenID4VP is a wrapper around other protocols, so its very extensible. Do we need to cap it in some way or profile it down.
Sam: Want to ensure we’re not mandated to support custom schemes.
Marcos: Is this just mdocs all the way down, if it is maybe we can revisit this
John: The EU have made it clear they won’t just accept mdocs
Hicham: Schemes are not the only problem. I see two protocols. OpenID4VP and a simple mdoc request protocol.
Lee: we should document the layering and make sure we’re clear on it. Credential formats: need to support more than mdoc. Too early to say its just mdoc. There’s enough privacy problems with mdoc. Not perfect. Then there’s the presentation protocol layer: even in mdoc, you still need to define this (query language, nonce, etc). Currently that is OpenID4VP. Need to have justification to create another one. Starting to see some of these pieces mandated.
Kyle: xkcd 14 standards so make another comic, could force regulators to rethink this and allow us to reset the regulation with better privacy characteristics along the way.