W 2024-09-25 14:45-15:45 PT
https://www.w3.org/events/meetings/456057ed-2184-4870-86a4-f01c8158d3c0/
Session Chair: Tim Cappalli, Heather Flanagan
Session Scribe(s): Heather Flanagan
Tim: this was a great topic last year and a lot has happened since then. Let’s chat. [agenda review]
If we split the problem statement
What is a custom scheme? “An identifier that an app can register with an operating system with the goal of being invoked from other contexts, such as other apps or from the web.” (from slides) It’s not a sustainable model.
Issues with custom schemes:
Learnings from passkeys
[timeline] FIDO wallet task force (2021) to IIW to WICG to OpenID+Digital Credential protocols collaboration and then W3C Federated identity WG (if FO lets us)
Core concept to digital credential model: issuer, holder/wallet, verifier; often referred to as a three-party model. Note no line between issuer and verifier; they do not need to be bound in real time; they are not supposed to be able to collude.
Closed-loop and open-loop concepts are coming into play as well. In closed-loop cases, the issuer and the verifier are in the same organization (i.e., government departments that already share information about citizens). In open-loop cases, there are no pre-arranged relationships.
Layering has been a big source of confusion for this work. The Digital Credential API takes a protocol string and a request. The request is defined in OID4VP or OID4VC; they in turn use ISO mDocs, IETF SD-JWTs, or W3C VCDM. That’s at least four different standards bodies owning different pieces of this puzzle. Then of course the app platforms have their part in this.
Ian: When you say “registry”, what is that?
Tim: currently it is in the spec, but there is work in the W3C to establish a registry process
Lee/Helen: Android DEMO
Martin: Does the wallet present that it's coming from Chrome as well as Android?
Lee: That's a design choice.
Martin: The representation the wallet makes to the user is about the information the browser has provided to it.
Lee: We do this with passkeys too; the password manager takes the consent. Right now it says who is making the call, and it’s probably obvious when you’re in the browser that the browser is making the call, so the data is there if you think it’s important.
Martin: it’s an interesting question
John: some wallets do not believe the browser is trusted and require a signed request from the verifier with keys.
Nick: one could make an enterprise case for this as well.
John: This is something of a philosophical fight about verifying the verifier and that we should trust cryptographic keys passed to us through the browser.
Lee: We can take that as feedback. We don’t do it for passkeys today, but it could be done. The data is there.
Tim: clarification, the verifier does not have to do anything for a cross-device flow.
Lee: You can see a lot of the UI challenges. There is friction built in on purpose.
Martin: although this is selective disclosure, if you don’t choose to disclose the info a website wants, the user is at an impasse.
Lee: That's the same as the situation today. It does allow us to offer help and mediate the situation.
Tim: the wallet can also show its own UI.
Lee: the goal is to make this a well-informed consent moment
Martin: to Tim’s point, this is a UI you’re showing on the web page to show what it’s asking for. Is there a way for a webpage to ask for things optionally?
Lee: There’s an anti-pattern here. You can say what’s critical and what isn’t, but if you allow the user to tick a box to let them select, then vendors may well overask. But there is support for conditional rather than user optional.
John: at least for the EU national ID scheme, RPs through some sort of trust framework will have to show what attributes they are legally allowed to collect. The euID wallets are going to enforce that regardless of what the UX will show. If they ask for something they are not allowed to, they just aren’t going to get a response from the wallet. Where it gets interesting is derivative credentials where issuers aren’t taking the same level of responsibility.
Martin: There is no way for the verifier to know if you chose not to present a non-critical field. Something to consider.
John: whether there should be a different experience between the verifier having a fiduciary responsibility or a browser having a fiduciary responsibility? Who is responsible for what kind of damage? Depends on what kind of wallet and credential.
(+1 bumblefudge — huge distinction between apples/freemarket credentials and oranges/trust-framework-presentation-constrained credentials)
Ian: Is there a way to do a recording of what was shared so the mediator can show what was actually shared and so shift liability back.
Lee: What you return is what you’re supposed to show. Do not consent to less data than was actually shared. They are mandated to keep a log of what was actively shared.
Ian: cryptographically?
Lee: Not cryptographically. It is not a blockchain ledger.
Ian: If there is a question of trust, is there a way to prove what happened?
Rick: It’s the wallet that has to be trusted and maintain a transaction log, so it doesn’t really matter if its signed or not.
John: those logs are sensitive because that’s all the information we’re trying to protect from people
Lee: it’s protected today because it’s what they’re protecting today
Tim: we’re in an interesting place because we’re in a situation with two user agents
Gerhard: Is there a way to indicate and be held accountable to what’s shared?
Lee: there are a lot of regulatory constraints, and the RP has to inform the user as to what they’re requesting the data for. Various issuers have decided that’s not good enough. In the EU, we expect verifiers to have to register what they’re going to request and why. For gov’t issued credentials, we see policies (aka, trust frameworks) but it's not universally applied. US DMVs do not have this yet, so anyone can request a mDL and it's up to the RP if that happens. There is no defined way of presenting that. Nick Doty has an idea about that but we’re not there yet.
John: We've been working on that in the DC4EU education work item. They have some interesting use cases with very different security properties. In SAML metadata, there are ways to indicate who gets what attribute bundles based on things like what federation or what university or what group a user belongs to. As wallets become more general purpose, others will decide they need similar things. For digital payments, knowing someone is a certified merchant will be important to know. Banks will also have to go through the regulatory process for what credentials they are requesting to KYC.
Martin: This is very encouraging. People are concerned that Starbucks will ask for your passport when you order your coffee so they know your name is correct. It is discouraging to hear about the uneven nature of how regions are doing this. That organizations can join more than one trust framework is definitely good. This comes back to being able to present history to know what was presented and under what trust framework.
Lee: The OID4VC json can be signed; the attributes of that cert can say what you’re allowed to request. Then you get non-reputable evidence of what you’re allowed to request.
Martin: It doesn't work for age verification, but it works for everything else.
John: You may want to do it for age verification if you have a trust mark that you have fiduciary responsibility to ask about age. A verifier will likely belong to many trust frameworks. In order to scale, they have to be able to sign and de-reference.
Vitali: Have heard that any app can register as a wallet. If any app can present itself as a wallet, and this three-party model has great privacy properties, what prevents me as an app maker to register as a wallet and can start collecting information about what is being asked and shared?
John: the user would have to select the credential; if the wallet doesn’t have a credential to reply with, no data is shared.
Vitali: Can a wallet lie?
Lee: We have ways to protect against that; we run their code in a sandbox. If they don’t get picked, they don’t learn anything. If they are picked but don’t have the credentials to answer the info, then things will fail. Also, this would be malicious use and there are enforcement mechanisms to handle that. Not sure its worth adding complexity to police abuse given we have other ways to handle this now (so don’t need to add more now)
Tim: Nick has been working within PING on user considerations for credentials on the Web; that’s worth reading up on. https://github.com/w3cping/credential-considerations/blob/main/credentials-considerations.md
Unlinkability and Google’s ZKP solution for predicates (10m)
Lee: The problem we’re trying to solve — there is our API. You have to define the request via the request protocol, and what’s returned is a credential in one of many potential formats that all have different properties. Some of those formats carry data that you didn’t request as part of the protocol. Example: when getting “over 18” you get more info: you reveal the issuer (issued by the CA DMV) and extra identifiers (signed by a unique device key, thus allowing cross site tracking). mDocs has an answer to this — single use keys, issued in batches; is effective. But that has a scalability problem, and you totally rely on the wallets of getting that right. Some wallets still reuse keys, so there’s no hard guarantee here. The other issue is the RP-Issuer collusion issue. One of the properties is that the issuer should not learn where you presented your credential. If the issuer and the RP collude, they can share info and see the device key, thus narrowing things down to the exact user. How big a problem is this in reality? YMMV.
Solutions? Most of the solutions on the table come down to Zero Knowledge Proofs (ZKPs).
[see also notes from the Digital Credentials call from August 2024]
Martin: What about 10 year old phones?
Lee: Don’t know, but this is being done on the regular CPU of current phones.
Lee: White paper will be released by end of year, and code released in January. This is potentially very exciting, but we do need to see how it is received.
Emil: where can we read the fancy math?
Lee: I’m told, December.
Martin: Are you looking to target delegatable anonymous credentials?
Lee: can’t hide the issuer entirely.
Martin: But what about “any of the issuers from this set?”
Lee: In theory, yes, but you would need to have a set.
Martin: Want to make sure people from outside the EU or US get a fair shake.
Lee: if the set is really big, not sure what that will do to performance.
Koichi Moriyama: What does verifier unlinkability mean?
Lee: if you share identifiable information, then none of this matters. This only matters when you are presenting something that asserts there is nothing in there that should allow unique identifiability. In the B2C, there _might_ be something identifiable, so we get the verifier-issuer unlinkability
Steve: On the RP, are there concerns about computational load?
Lee: RPs have to run something too, so that will require resources. Maybe that makes you think twice about asking for the data.
Ben: The issuer-verifier linkability being in the pilot is a bummer and a requirement of the art because the law calls out not having that as a requirement. That’s wild and concerning.
Lee: May have to write to the EU Parliament.
Martin: Fun fact: some of the legal text calls for “unlikeability”