WICG
User agents that only support authorized verifiers (for government credentials)
With verifier authorization generally being optional in frameworks such as the EUDI ARF, it seems that some user agents would find it desirable to restrict their support for government credentials to verifiers that have undergone some registration and certification process with the issuer / the government.
@marcoscaceres's comment in https://github.com/w3c-fedid/digital-credentials/pull/262#discussion_r2148884783 makes it sound like that is the requirement WebKit ships today. Marcos, can you comment more on this?
I believe that @martinthomson mentioned to me that such a limitation could also be desirable for Mozilla
Even if a user agent does not want to outright block requests from unauthorized verifiers, it might be desirable to increase user friction and show some kind of warning.
Assuming that there are > 0 implementers that desire this, is this something that should be defined more formally in the DC API spec?
I should say that there are some big technical and non-technical challenges that would have to be figured out first - if a request is signed, how does the browser verify that signature? Is this a system that will establish itself in practice, and does it scale globally? There's probably more.
I agree. At one point I had talked with some OpenID4VP folks about having a 'bit' in the request that says the wallet must reject unless the verifier had been explicitly authenticated. That never happened, but maybe it is possible to do at the DC API and platform layers instead?
@leecam any thoughts for Android?
Preserving a comment from @burdges on #262 on this topic:
If a credential C proves attributes of end users to some credential verifier V, then the credential C should never be used without the user agent first verifying some certificate C-V-DPA of the credential verifier V. This certificate C-V-DPA must be issued by a competent data protection authority DPA in EU terms, and specify the attributes, or attribute combinations, this specific credential verifier V may request of the end user.
In real world terms, if you say present and id at a bank or airport then you know you're physically in that bank or airport, but users have minimal idea if a website is legitimate when you present id there. You might've lIoydsbank.com when you wanted lloydsbank.com for example. It's already problematic that users type their PII into random websites, but if users can now prove their PII then the proving system itself should enforce that verifiers submit to whatever DPA the credential issuer requires.
At least in the EU, there already exist DPAs with considerable legal authority, so it seems insane for the credential system to prove attributes about the users, without first using a more conventional certificate-like infrastructure to verify the credential verifiers.
As some have pointed out, there are DPAs like Ireland who would ruber stamp credential verifiers, but really the credential issuer should determnine the required root DPA for verifier certification. A user agent holding a credential issued by France should always require a root certificate by France's national DPA before signing anything. A French DPA could then certify the Irish DPA, or a private auditing company, to certify end user credential verifiers, just like in regular certificate chains, or then later revoke that authorization, say after detecting abuse. Also, revocations should propagate through existing certificate revocation list infrastructure, which recently saw major upgrade.
All these techniques seem well established, but they should become practice from day one.
I raised this here earlier: #35 (comment)
Apple mentioned that "domain verification" was available for verifiers issuing requests (from the wallet?). Is it explicitly stated somewhere how they accomplish this? Generally, I do wish for more proactive measures before the request comes to the holder. By the time a potentially abusive request comes, it had gone too far.
Apple mentioned that "domain verification" was available for verifiers issuing requests (from the wallet?). Is it explicitly stated somewhere how they accomplish this? Generally, I do wish for more proactive measures before the request comes to the holder. By the time a potentially abusive request comes, it had gone too far.
@zoracon this is at the protocol level (ISO 18013-5 reader authentication)
Apple mentioned that "domain verification" was available for verifiers issuing requests (from the wallet?). Is it explicitly stated somewhere how they accomplish this? Generally, I do wish for more proactive measures before the request comes to the holder. By the time a potentially abusive request comes, it had gone too far.
@zoracon this is at the protocol level (ISO 18013-5 reader authentication)
Thank you, I will have to either look at my old purchased copy or purchase a new one since it's been a few years. Not being an open standard there's friction tracking this. Is it still listed as "optional" for reader auth? And does that apply to online verification since last I checked, people referencing in-person presentation of a physical reader?