what restrictions can the issuer put on wallets that it provisions into?

[npdoty]

Raised by @kdenhartog, and a side conversation on a few different calls recently:

Do we assume that the wallet can decide/approve/limit what wallets a credential is issued into? Is that to ensure security/privacy protections, or also for any other purposes that the issuer has?

Does that also assume that the credential is bound and that the user must be prevented from transferring it to another wallet or device of their choice?

This group mostly hasn't looked at the provisioning/issuance side, but it keeps coming up and may be relevant.

[npdoty]

This may be related to the concern about irresponsible wallets and wallet attestations (as discussed on the 12 February and 21 February calls).

[Willewragtag]

Speaking on behalf of issuers of government issued identification credentials (specifically the DMVs), we certainly have a need to check if a wallet is suitable. We need to make sure that the wallet complies with a predetermined set of security, privacy and interoperability requirements. If a DMV does not check, as far as is practicable, the privacy, security and interoperability features of a wallet into which they provision, it is likely that some wallets will be insufficient in some or even all of these areas and will result in negative consequences for the wallet holder. DMV administrators have indicated that based on past experience they would be the first ones to be held liable by their customers if something were to go wrong.

And the issue is not limited to only the wallet. In future, when we get to the 2nd edition of ISO/IEC 18013-7, an issuer will also have to confirm, at the point of issuing, that the wallet/OS/HW combination can be trusted to perform holder authentication on behalf of the issuer at transaction time. (This design ensures that the verifier will continue to have only one trust point.) If a DMV is not allowed to do this check it will break the trust architecture.

Both the above cases of course argue for not allowing a wallet user to transfer a credential to a different device without involvement of the issuer.

[kdenhartog]

Speaking on behalf of issuers of government issued identification credentials (specifically the DMVs), we certainly have a need to check if a wallet is suitable. We need to make sure that the wallet complies with a predetermined set of security, privacy and interoperability requirements. If a DMV does not check, as far as is practicable, the privacy, security and interoperability features of a wallet into which they provision, it is likely that some wallets will be insufficient in some or even all of these areas and will result in negative consequences for the wallet holder. DMV administrators have indicated that based on past experience they would be the first ones to be held liable by their customers if something were to go wrong.

And the issue is not limited to only the wallet. In future, when we get to the 2nd edition of ISO/IEC 18013-7, an issuer will also have to confirm, at the point of issuing, that the wallet/OS/HW combination can be trusted to perform holder authentication on behalf of the issuer at transaction time. (This design ensures that the verifier will continue to have only one trust point.) If a DMV is not allowed to do this check it will break the trust architecture.

The issue with this design is that it relies on flawed assumptions in the architectures that historically have not worked on the web. For example, EME doesn't prevent torrenting or other work arounds to protect media files, Passkey best practice is to not require attestations of authenticators because it reduces deployments, and Web Environment Integrity API  faced a large amount of backlash when making similar arguments for advertising.

Furthermore, it eliminates the usage of this API from most Linux operating systems since they are unlikely to be able to "attest" to your trust architecture in a satisfactory manner given their focus on user first and user controlled software.

Specifically with regards to this:

If a DMV does not check, as far as is practicable, the privacy, security and interoperability features of a wallet into which they provision, it is likely that some wallets will be insufficient in some or even all of these areas and will result in negative consequences for the wallet holder. DMV administrators have indicated that based on past experience they would be the first ones to be held liable by their customers if something were to go wrong.

I'm a bit surprised this is the conclusion that's been reached by DMVs. If a user shows up at a phishing site they don't think their browser failed them. They think that the site is bad. It seems that traditions, cultures, and beliefs of high assurance credentials (e.g. passports are owned by the government and loaned to the subject or a person shouldn't take a photograph of their drivers license) are leading to a leaky abstraction of technical requirements that are being placed on browser APIs now because of these specific use cases. Unfortunately, this design doesn't seem to align with the way the open web has worked and I personally don't believe that this should be another example of a reason to justify this. Especially because doing so will likely lead to side effect abuses. Just one example of this would be that a site would require the supply of an mDL credential not because they care about the attested data, but rather because it supplies a non explicit assertion that the software and hardware being used are integrity protected which is not what this API is designed for.

[timcappalli]

Parking this issue for future discussion where .create methods are discussed.

[Sakurann]

not sure how this issue is relevant to the API design.

for presentation, the trust model is such that if the verifier trusts the signature/MAC of the issuer on the credential, it also trusts that the issuer have checked that that wallet meets all the requirements. in the EU, there is a requirement to enable wallet attestation during presentation for cases where issuer might have revoked the entire wallet after the issuer has done all the checks and issued into that wallet (need to file a separate issue on that - it is in openid4vp layer how to request/return that wallet attestation, but might have some implications on the matcher UX).

for issuance, issuer needs to check the wallet security posture, but don't think that is relevant to the API design. in a sense that, where API is needed during issuance is issuer invoking the wallet (for example, credential offer in openid4VCI), and issuer checking the wallet happens in a request that happens after that invocation step.

[dlongley]

for presentation, the trust model is such that if the verifier trusts the signature/MAC of the issuer on the credential, it also trusts that the issuer have checked that that wallet meets all the requirements. in the EU...

We should be careful not to assume this trust model will be used for all credentials that can flow through the Digital Credentials API (I would assert that it won't).

It's one thing to say that a particular ecosystem attempts to enforce strict software restrictions through "chain of custody rules" all the way from issuer through holder through verifier, as if a credential is an authorization rather than merely a set of claims, but not every ecosystem will work that way. Some will be more open, allowing users, for example, to transfer credentials between different wallets without asking for issuer permission.

The Digital Credentials API should be flexible enough to handle use cases where digital wallets act as user agents (specifically for credential purposes, not as "browsers") and are not, for example, treated as oauth-style applications.