I'd say that this principle applies to both directions.

Website -> request to wallet -> learns nothing if consent is denied.

Wallet -> accepts / responds to request -> browser learns nothing other than consent was obtained in the wallet, and RP / verifier accepted or rejected the encrypted presentation.

If the browser learns anything about "specific credential attributes", the user needs to consent to that, because otherwise a user is consenting to "disclosing they have a specific credential type", when they consent to disclosing an encrypted presentation for a plaintext query.

"When making the API call, the website should not learn anything about the user's credentials or wallets unless the user agent has gained explicit user consent. Likewise wallet applications will not learn anything about a given request unless the user explicitly consents to select a credential from that wallet"

This principle may put certain constraints on things like silent enumerate APIs or feature detection APIs. It likely also places a constraint on what information is required to be passed in the initial request and how wallets perform matching.

I think I agree with this principle, but I'm not sure how it's written above is rigorous enough for people to know whether we'd be agreeing/disagreeing to the same thing. Specifically, what the user must consent to is unclear, but I agree that neither the website nor any wallet provider should learn anything about a request "automatically", with no consent from the user.

I think the relationship the user has with a website (RP/verifier) is (more often than not) expected to be quite different from the one it has with a wallet provider. In particular, at least for some wallets, a user may consider the wallet to be very similar to a user agent, whereas I don't expect this to be the case with the website.

I think the website should not learn anything at all until, at minimum, the user has consented to use a particular wallet in a particular exchange -- and has also had time to interact with the wallet. That wallet may be able to help the user decide whether to proceed with the interaction with the verifier in ways that the browser is incapable of doing.

In terms of what consent is required from the user prior to the wallet learning anything, I think this minimally involves the user being made very aware that a specific website is making a credential request. Consent could be obtained in the form of user selection of a wallet to proceed with the request. I don't necessarily think that the browser needs to have any deep understanding of what the credential request is (e.g., type information), nor do I necessarily think that will even be particularly effective as a protection mechanism, given that exchange protocols can freely communicate anything between the verifier and chosen wallet without the browser's mediation.

I can understand the desire to surface this type information prior to wallet selection -- and have seen many discussions about it -- but I don't know how feasible it is without crippling the utility of the API or turning the browser into a wallet. A better understanding/discussion of the relationship the user is expected to have with their user agent and with their wallet(s) might be required. It may also be the case that users should be able to register different wallets with different levels of trust with their browser, some that have a similar level of trust as a user agent, and others that are much more restricted in use (e.g., restricted to a handful of specific credential types that could be surfaced). I'm thinking about two main categories: in the former, highly-trusted general purpose credential wallets and, in the latter, one-off single credential wallet apps, often issuer-provided.

"Likewise wallet applications will not learn anything about a given request unless the user explicitly consents to select a credential from that wallet"

How shall the wallet indicate it knows/maintains a certain credential without knowing what credential is being requested?

It registers them with the OS.

That's not how the matcher mechanism works, right? As far as I understand, the OS/Browser asks the Wallet to match a request.

That's how the matchers work.

The matchers are provided by the wallet (when the wallet registers the credentials they hold to the OS), so it is wallet (webasm) code, but it is run in a (OS) sandbox, so that while the code is provided by the wallet, it has no communication channel out of the sandbox (e.g. access to the network or FS). So, the wallet is able to offer matches (hence the name, matchers) without the privacy drawbacks (e.g. it doesn't learn anything about the request, until the user selects the credentials that was matched).

It registers them with the OS.

LIke - it registers like credential metadata with the OS? Or registers some restricted code that can look at the request and return an indication if it has a credential that could satisfy the request? Or something else entirely? Or are these (implementation) specifics that are still being ironed out? Sorry for the question - just trying to keep up with things.

It registers credentials metadata (e.g. the attributes, values, etc) that it chooses to and thinks is sufficient to provide good matches (i.e. the query language + metadata + wasm needs to be sufficient to provide good matches).

When a request is made we need to ping each of the wallets and ask the wallet which credentials match the request.

As Sam says on Android we do ask the wallet to match the request (its not done by the OS itself). We do this by running some wallet provided code+metadata in a sandbox when a request is made. There is a new API to allow wallet apps to configure their matching code and associated metadata.

There is a new API

@leecam just for completeness in the conversation, this is an app platform API, correct? (e.g. an Android OS API)

There is a new API

@leecam just for completeness in the conversation, this is an app platform API, correct? (e.g. an Android OS API)

Yeah sorry, this one is an Android API for use by wallet applications.

I agree with not being able to query what's in wallets until the user grants permission. That seems like table stakes for any credentials API.

However, I'm not sure I read correctly but there seems to be an implication that even being able to identify whether the user has Wallet A, B, or C should require authorization from the user? I see a number of problems with that. Wouldn't it make more UX and interop sense to be able to freely discover what wallets the user has installed on their device? In fact, that also seems table stakes for any credentials API. Without it wallet interop and selection seems to become much more difficult and gated behind yet another pop up.

For privacy reasons we wouldn't want websites to be able to silently query which wallet apps the user has installed. It could both be used as a fingerprint for the user and it may reveal sensitive user information, such as their citizenship or state of residence.
Indeed in the proposed API, the website need not learn the identity of the wallet that provided a credential, even after a fully consented transaction.

In the current proof of concepts, when a request is made the OS polls each of the installed wallets and collects the aggregate list of matching credentials and renders a single popup asking the user which credential to proceed with. Once a user selects a credential the system hands off to that wallet application to continue the flow. We hope this provides a slick selection UX and allows for any wallet app to interop with the API

That's brilliant to abstract away the app selection entirely from the user and then call the app at the end of it automatically. How would this work for issuance though?

So far the group has only focused on the presentation API. That said we've informally discussed a similar approach for issuance. A website would make an API call to save a credential. The platform would again query each of the wallet apps (in the sandbox for Android) and ask if they are able to store this type of credential. This time the system would provide a wallet selection UI, listing all the wallets that report that they are a viable candidate. Once the user picks a wallet the platform hands off the flow to that wallet to complete the enrollment. Likewise the other wallets on the system learn nothing of the issuance request.

As i say though, the issuance flow has not been discussed at length by the group yet, this is just some initial thinking

For the moment, issuing credentials is a lower priority. We do have ways in OID4VCI etc for an issuer to make an offer to the wallet. Most of the high value wallets will likely be tightly bound to the issuer. As an example the EUDI wallet has a requirement that the whole wallet can be revoked by the PID issuer as I understand it. (perhaps not the best place for other credentials) Those wallets will be preconfigured to do identity confirmation and retrieve PID or MDL from their known issuers. I see the browser API having a role in provisioning for lower-security credentials. As an example, United Airlines wants to issue a loyalty card for re-authentication to their site and perhaps other partners. They may allow that to be issued into multiple wallets. However, they may want to filter wallets via some sort of trust mark or approved list. That is where there needs to be standardization so that the matcher can guide the user to a wallet that meets the issuers requirements without allowing enumeration of all the wallets.

I do think we need that but presentment is I think a higher priority to get done.

@ve7jtb wrote:

Those wallets will be preconfigured to do identity confirmation and retrieve PID or MDL from their known issuers.

Isn't this a recipe for pervasive tracking of individuals using their government-issued digital credentials? If we presume an issuer is going to bind strongly to their wallet app, and that wallet app gets to know when/who is requesting a VC, then doesn't it follow that the government then gets to track your usage of their credential no matter where you use it?

One of the design goals for this ecosystem was to allow 3rd party wallets who wouldn't "phone home", but if we presume the ecosystem starts w/ issuer-bound wallets/apps, then we incentivize "phone home" and pervasive tracking by the issuer.

Most of the high value wallets will likely be tightly bound to the issuer.

While this may be true for some, the U.S. Citizenship and Immigration Services, an issuer of some of the highest value credentials issued by the US Government, has publicly articulated they are seeking to issue credentials, such as the U.S. Permanent Resident Card, U.S. Employment Authorization Document, Certificates of U.S. Citizenship etc. into digital wallets that meet their "... requirements for security, privacy, and interoperability, such that the holder can assert U.S. immigration
status, residency, and employment eligibility with both public and private sector verifiers" [1]

[1] DHS Privacy Preserving Digital Credential Wallets and Verifiers Solicitation - Section 1.3.1

Raised #89 to provide some basic scoping statements around this concept.

It also seems like we don't have a "Design Goals" section in the specification, which might be where this sort of language should go.

I agree with the original statement in this issue.