Verifier/Relying Parties need to be able to verify authenticity and validity of (European Digital Identity) Wallets

[tlodderstedt]

The eIDAS regulation has the following text: Article 5a, 5., (a), viii 'European Digital Identity Wallets shall, in particular (…) support common protocols and interfaces (…) for relying parties to verify the authenticity and validity of European Digital Identity Wallets;'

We need to come up with means to allow wallets to comply with this requirement.

I assume EUDI Wallets will have a credential, referred to with different terms such as "Wallet Instance Attestation" or "Wallet Attestation" or "Wallet Trust Anchor", which it could present to the Verifier along with a Proof of Possession (PoP) of the respective key in the credential. I will use the term Wallet Attestation in this text. The Wallet Attestation is issued by a trusted party, which can assert the authenticity and validity of the wallet. I also assume the Verifier explicitly requests the authenticity/validity check.

I see the following options to build support into the protocol:

1. The Wallet sends a Wallet Attestation with a PoP in the POST request to the request URI of the Verifier. That's the earliest point where the authentication can happen. It would require an extension to the POST request. The Verifier could indicates in the authorization request that it requires Wallet authentication along with a fresh nonce the PoP must incorporate. It would also be possible the Verifier responds with a 401 in the POST request (providng a nonce) and the Wallet needs to send the request again, this time with the Wallet Attestation and PoP. The syntax could leverage syntax as defined in the "attestation based client authentication" draft.
2. The Verifier requests the Wallet Attestation like any other Attestation in the Request. The Wallet Attestation is provided in the vp_token. This option would not require any change to the spec.
3. The Verifier requests the Wallet Attestation with a special parameter in the request, the Wallet Attestation's PoP key is used to sign the Response. The Wallet Attestation is provided in a JOSE header of the JARM response structure.

[c2bo]

1) I do not believe this gives us enough flexibility and is too early in the flow and might create privacy problems or unnecessary errors/retries. 2) Without spending a lot of time to think about the finer details, this definitely would be my favourite solution. We just handle the wallet attestation like any other kind of credential (which it is). My biggest concern for this option would be that we probably need to handle user interaction differently - this is not a "normal" credential where the user should see requested claims, but should just see that a wallet attestation was requested. That means if we want to use vp_token, we need some form of signal for the browser API to understand this as a "special" request 3) This would definitely be an option, but feels like we are doubling something that could just leverage existing things in vp_token

That said, we should start a discussion if PIDs with an expiration time of a few weeks and a wallet attestation that is getting checked during issuance do not provide enough security without enforcing a proof of wallet attestation towards relying parties. I fear that this might create more problems (privacy, system complexity and UX) than it might bring benefits.

[jogu]

I think who authenticates first is a key question between 1 vs 2 / 3. It feels to me like it's sensible if the verifier authenticates first but that probably needs more consideration.

I am dubious that '2' requires no changes to the spec. I can't see which existing credential format profile would really work so we'd need a new credential format profile in VP I think. I think all options work without needing any changes to the current proposed browser API.

[paulbastian]

Option 1 is something that I voted against explicitly in the request_uri POST discussion, this may bring privacy issues and it seems natural that Verifier authenticates first.

Option 2 seems very easy, but it may bring troubles with a) wallets need special treatment for this credential and b) we can only request/send one credential in the Browser API?

Option 3 or similar looks best to me. wallet attestation should be passed alongside the vp_token, but not inside the vp_token imo.

[peppelinux]

@tlodderstedt "Wallet Trust Anchor" -> "Wallet Trust Evidence", since the term Trust Anchor is something well established in the literature and refers to an entity, not to an artifact (see epic 09 thread).

1. It was the first Italian implementation proposal, utilizing DPoP.
2. This is the current Italian implementation, where the provisioning of the WIA to the request_uri endpoint was abandoned in favor of the request_uri extension, thefore the WIA is provided withing the vp_token, as an entry of the vp_token array.
3. I'm not in favor of this, since, as you mentioned, the W(I)A or WTE is a verifiable credential like any other. I would prefer to normalize it in a flat model without any special/custom parameters.

@jogu I believe it requires no changes in the specs, as it would be another credential within the presentation definition object.

@paulbastian I cannot imagine a world where an RP can only request one credential at a time! It would also be a UX nightmare for people who need to present multiple credentials to access a single service. Regarding option 3: WIA/WTE should be treated in terms of interoperability like any other type of credential. It's up to the RP to assign value and meaning to its request, while the wallet instance should recognize that credential type to convey its significance to the user upon release.

[paulbastian]

I didn't design the browser API, I'm just sharing my observations. If it is yet another credential, the wallet needs special rules to not display this particular one to the user, as the average user doesn't understand the meaning.

[jogu]

@peppelinux

I believe it requires no changes in the specs, as it would be another credential within the presentation definition object.

I think we must mean different things by "no changes in the specs". I cannot see how you can achieve this without someone defining a new VP credential format profile, unless there is an existing credential format profile somewhere that fills this need?

I cannot imagine a world where an RP can only request one credential at a time!

This is the design of the current Browser API. Or at least, in particular, it is based on the assumption that a single wallet will satisfy the entire request and that the user selects only a single "credential" at the browser level. You may want to attend the https://github.com/WICG/digital-identities calls :)

[peppelinux]

@jogu you're right, that's why in my understanding openid4vp should not be the specification where we define new credentials types or formats, since it is, or should be, neutral for these kind of data. As the eIDAS PID is defined elsewhere and not in the openid4vp and so on.

This is the design of the current Browser API.

yes, that's why I would make @paulbastian 's words mine. I/We didn't designed that, we find a gap and we should talk about this evidence to get Browser API improving.

You may want to attend the https://github.com/WICG/digital-identities calls :)

thank you :heart:

[bc-pi]

IMHO a signature on the response seems the most natural approach here. So I'd favor 3. Seems 2 could work somewhat similarly but could be potentially awkward and problematic in a number of ways to put this wallet thing at the same location next to other user credential(s). I'm very much opposed to 1.

[David-Chadwick]

Interestingly the eIDAS requirement is in direct contradiction to the W3C VCDM which states

This trust model differentiates itself from other trust models by ensuring the: Issuer and the verifier do not need to trust the repository. [i.e. wallet]

Therefore I think we should question why eIDAS has this spurious requirement. Clearly the user must trust their own wallet, but the verifier gets a signed credential from the issuer (via the user) so why does it need to worry about how it was stored in between?

[paulbastian]

@David-Chadwick we stated these points multiple times in the eIDAS process, you probably don't need to convince anybody in this thread that the verifier doesn't need this proof. But now it's in the legislative text.

However the issuer does need it and this is where W3C folks did not agree on when we started introducing the wallet attestation concept two years ago. Many people still believe the wallet is a trustless container. But let's stick to the topic.

[David-Chadwick]

@paulbastian I don't think anybody believes the wallet is a trustless container. The user needs to trust their wallet, otherwise they would not use it. Would you store dollar notes in a wallet with a hole in the bottom? I can see an argument for the issuer wanting to protect the user and its credential by validating the wallet, but I can see no argument for the verifier knowing anything about the wallet. I think we should ignore the eIDAS requirement and say that OID4VP does not fulfil this requirement.

[tplooker]

I think option 3 is the most natural here too, If option 2 is meant to imply the wallet attestation should be treated like any other credential, I think that could become messy. While I understand the desire to authenticate the wallet early in the flow, which I believe is the motivation for option 1, I don't think that solution will be workable, especially in the browser api. Option 3 is also most similar to web authn attestation IMO too which is perhaps relevant precedent here.

[paulbastian]

Could it make sense to use attestation based client authentication if we follow the proposal from IETF to make it headers?

Edit: may be difficult as the verifier is the client in OpenID4VP

[tplooker]

Could it make sense to use attestation based client authentication if we follow the proposal from IETF to make it headers?

I think generally the attestation structure we've defined, with an Attestation and Attestation PoP make sense, its probably the notion of grounding this as a "Client Attestation" because of the OAuth2 protocol doesn't work when applied to OpenID4VP, in any case its something I think we should discuss more.

[jogu]

Could it make sense to use attestation based client authentication if we follow the proposal from IETF to make it headers?

If we're returning the wallet attestation with the presented credential, this would make it harder to return the wallet attestation via the browser API.

Edit: may be difficult as the verifier is the client in OpenID4VP

As Brian hints at above the more traditional OAuth way to show which authorization server (i.e. wallet) is the source of a response would be a JARM signed response.

[tlodderstedt]

I'm in favor of option 3 as it provides the attestation along with a binding of the presented credentials.

Option 2: The wallet attestation is a special function and a special feature. Requesting and providing it like any other credential requires the wallet to have special treatment in the user consent flow. Option 1 discloses the wallet data pretty early before the verifier is reliably authenticated.

[awoie]

Just trying to make sure we didn't miss any other options. Would it make sense to include the wallet attestation in the verifiable credential, so that it gets sent automatically with every presentation? In that case, the verifier does not have to request the wallet attestation in every request.

[peppelinux]

@awoie in my opinion, wallet attestation and issued credentials have different lifecycles and purposes, as well as being distinct objects.

deciding between option 2 and option 3 I can see in both of them much sense.

Option 2 normalizes the approach bringing the wallet attestation as any other presented credential, giving to the RP the power to mandate it.

Option 3 embeds the wallet attestation in the response, forcing RP to get it anyway. This has different impacts on the implementations.

At the end, if Option 3 appears the best solution (that allows to reduce the complexity of each requested presentation_definition as well, removing also the burden to define a sort of credential type identifier for the wallet attestation ...) I can peacefully agree with that.

My last question about option 3. How an RP would request the presentation of the wallet attestation within the response headers? and: how an RP would reject a vp_token if the wallet attestation would not been included in the response?

I'm sure that the answers are not challenging, I just want to bring those retorical questions to bring awareness about some common requirements to make option 3 eligibile.

[paulbastian]

Just trying to make sure we didn't miss any other options. Would it make sense to include the wallet attestation in the verifiable credential, so that it gets sent automatically with every presentation? In that case, the verifier does not have to request the wallet attestation in every request.

Agree, the lifecycles are probably different, so this is not a good choice.

[paulbastian]

@ve7jtb Whats your opinion?

[paulbastian]

Discussion within IDunion summarized:

• Option 2 is preferred by some for simplicity, UI/UX flow exceptions seem bearable
• Option 3 seems also viable, ideas came up to use HTTP Headers within Authorization Response according to the new discussion for Attestation-Based Client Authentication (which is ok, because it is not only client authentication any longer) -> maybe this is Option 4

[bc-pi]

ideas came up to use HTTP Headers within Authorization Response according to the new discussion for Attestation-Based Client Authentication (which is ok, because it is not only client authentication any longer) -> maybe this is Option 4

Many/most methods of delivering the Authorization Response don't have a means for the wallet to set headers so the applicability of that is limited.

[paolo-de-rosa]

The requirement for mutual authentication stems from mandates outlined below:

1. Article 5a, 5(a) (vii): "European Digital Identity Wallets shall, in particular: ... support common protocols and interfaces: ... for authenticating and identifying relying parties by implementing authentication mechanisms in accordance with Article 5b;"
2. Article 5a, 5(a) (viii): "European Digital Identity Wallets shall, in particular: ... support common protocols and interfaces: ... for relying parties to verify the authenticity and validity of European Digital Identity Wallets;"
3. Article 5a, 8 (a): "Member States shall provide validation mechanisms free-of-charge, in order to: ensure that the authenticity and validity of European Digital Identity Wallets can be verified;"
4. Article 5a, 8 (b): "Member States shall provide validation mechanisms free-of-charge, in order to: allow users to verify the authenticity and validity of the identity of relying parties registered in accordance with Article 5b."
5. Article 5a, 9 (a,b,c): Member States shall ensure that the validity of the European Digital Identity Wallet can be revoked in the following circumstances: (a) upon the explicit request of the user; (b) where the security of the The key provisions are summarized as follows: has been compromised; (c) upon the death of the user or cease of activity of the legal person.

In particular for this discussion points 2 and 3 emphasise the need for interfaces and protocols that enable the relying parties to verify the authenticity and validity of the "European Digital Identity Wallet." It remains ambiguous whether this refers to the wallet as a solution or as an individual instance. Point 5 makes clear that the co-legislators intend for the revocation of individual wallet instances under three specific circumstances and not necessary the whole Wallet Solution.

So given the points 2,3,5 proposed option 3 seems to be the best approach as it offers the attestation combined with a binding of the presented credentials. Obviously privacy considerations need to be made but for now, I am personally open to accepting a threat model that assumes issuers do not collude with relying parties (RPs), and that RPs do not collude with each other, given that there are sufficient checks and balances in place to make such abuses unlikely.

[danielfett]

Obviously privacy considerations need to be made but for now, I am personally open to accepting a threat model that assumes issuers do not collude with relying parties (RPs), and that RPs do not collude with each other, given that there are sufficient checks and balances in place to make such abuses unlikely.

Such a threat model would be a dangerous assumption; it would essentially allow for the introduction of a universal identifier for European citizens through the backdoor. This would (rightfully so) raise concerns among privacy advocates and be a hindrance to widespread adoption.

Furthermore, it would at least partially undermine selective disclosure: RPs can combine data from multiple, independent presentations, even if the user made them in independent use cases.

[tlodderstedt]

I think @paolo-de-rosa wanted to remind us of the additional safeguards beyond technical solutions, especially in the EU with GDPR and eIDAS, that might kick in if we don't find a perfect privacy preserving solution. However, we definitely should aim for the best possible privacy preserving solution.

[paolo-de-rosa]

Such a threat model would be a dangerous assumption; it would essentially allow for the introduction of a universal identifier for European citizens through the backdoor. This would (rightfully so) raise concerns among privacy advocates and be a hindrance to widespread adoption.

Furthermore, it would at least partially undermine selective disclosure: RPs can combine data from multiple, independent presentations, even if the user made them in independent use cases.

The discussion appears somewhat off-topic as it doesn't seem that the other proposed options can address or mitigate the risks associated with the mentioned threat. If we're focusing solely on my opinion of the threat model, I wouldn't isolate it from the context. However, I'm open to engaging in a more comprehensive discussion about privacy threat modeling.

Given the requirements, particularly regarding the revocation of a wallet instance, I'm eager to explore better solutions or mitigation that address the privacy concerns related to wallet instance authentication.

The protocol should be developed according to privacy-by-design principles that minimize privacy risks to the greatest extent possible, while also considering other requirements and cost-effectiveness. At the same time it's foundamental to recognize the wallet as part of a complex system that includes technology, legal frameworks, and societal norms. Therefore, multi-level mitigations will be implemented to address potential privacy risks that cannot be addressed by technological solutions.

Furthermore, it is important to avoid an overly technocratic or technology-centric approach that dismisses legal frameworks and overlooks societal norms by focusing exclusively on technological solutions to prevent privacy issues. Such an approach is ineffective because it would lead to the rejection of many technologies, such as mobile phones. In fact there is no technical solution preventing a Mobile Network Operator to collude with other operators or monitor activities of the users but only law, law enforcement and societal rules.

[Sakurann]

John (@ve7jtb): unless wallet attestation is presentation instance specific, it is a correlation factor. so in that case wallet attestation is "just" another credential presentation, so treating it as such (option 2) is least confusing. who is verifier trusting for wallet attestation validity? what is its lifecycle. John potentially also suggested option 4 where wallet attestation (as a digital credential presentation) is inside credential presentation.

[peppelinux]

John potentially also suggested option 4 where wallet attestation (as a digital credential presentation) is inside credential presentation.

what about presenting more than a single credential within a single presentation?

Should we consider that "inside credential presentation" refers to a data format-specific presentation within the SD-JWT VC presentation or within the mdoc CBOR in the vp_token array, or does it refer to the entire vp_token array, where a single wallet instance attestation is an entry within that array?

[ssanchocanela]

John (@ve7jtb): unless wallet attestation is presentation instance specific, it is a correlation factor. so in that case wallet attestation is "just" another credential presentation, so treating it as such (option 2) is least confusing. who is verifier trusting for wallet attestation validity? what is its lifecycle. John potentially also suggested option 4 where wallet attestation (as a digital credential presentation) is inside credential presentation.

From my point of view, the scenario in which WIA is presentation instance specific is creating correlation on the other side, on the WIA issuer, aka Wallet provider.

[ssanchocanela]

I am probably arriving late to this discussion. I don't know whether there is a decision taken or not.

• Option 2 seems to be more agnostic. WIA is another credential and we put all the logic on the Wallet to manage it. The verifier can request several credentials using input_descriptors.
• Option 3 is creating some an exception as it is not global. As a solution, it seems to be good. I understand that in the Presentation Definition, a special parameter is introduced so the Wallet knows that along with the other credentials a WIA shall be presented.

For me both options are good.

[alenhorvat]

In EBSI (https://hub.ebsi.eu/vc-framework/trust-model/policies) we established such a framework that enables

• mutual authentication
• restricting VC sharing to prevent oversharing The framework is protocol (and format) independent and can work with OID4VP or any other.

Options are

• "active" mutual authentication (both parties provide challenges, responses)
• "passive" RP/Verifier authentication (RP provides the necessary information under the .well-known or in the authorisation response).

wrt traceability: that's a separate design topic that is addressing how public key or wallet attestations are issued and used. In the design above, this construct is completely separated and different options exist. If necessary, we can publish the different strategies we converged to with the EBSI use cases.

In summary, there are 3 dimensions

• mutual authentication
• limiting/restricting oversharing
• key attestation and traceability

Hope, this helps.

[tlodderstedt]

@ssanchocanela the question is whether we can keep the design universal for 2. if so, no extension to OID4VP would needed and every ecosystem can decide what format and credential type/schema to use for WIAs.

For the EUDIW, for example, we would just need to define a credential type "WalletInstanceAttestation" in the ARF and are done.

I would prefer that.

[ssanchocanela]

I prefer option 2 too.

[jogu]

Discussed on this/last week's working group calls - we should confirm with the browser folks that requesting/returning multiple credentials in the way suggested in '2' is going to work okay. Possible concerns over the need to have a new wallet attestation for each presentation to avoid linkability.

[ssanchocanela]

Discussed on this/last week's working group calls - we should confirm with the browser folks that requesting/returning multiple credentials in the way suggested in '2' is going to work okay. Possible concerns over the need to have a new wallet attestation for each presentation to avoid linkability.

From my view "have a new wallet attestation for each presentation to avoid likability" is not related to the specification we are discussing. This is a legal requirement coming from eIDAS2 and translated into a requirement for the EUDI Wallet. This is a mechanism that is beyond the standard.

[TomCJones]

Wallets are used with no internet connection - it seems that including them in a group that claims to the internet only is basically out-of-scope.

[Sakurann]

Discussed in a WG call:

• rough consensus with option 2.
  • some people leaning toward a new suggestion to use a new top level parameter at the level of vp_token and presentation_submission.
• wallet attestation credential format/schema is defined elsewhere.
• OpenID4VP only defines how to pass wallet attestation in a VP Token.
• privacy considerations that wallet attestation needs the same unlinkability considerations as credentials
• technical mechanism how request wallet attestation in the presentation request (special reserved credential type identifier? or an override over a credential format?). and implementation considerations on the UX. so that the wallet knows how to deal with this wallet attestation credential separately from other credentials with user's attributes.
• might require some clarifications on the browser API text about multiple credentials

[TomCJones]

Here is a mobile assurance statement that could be used in the way intended https://kantarainitiative.org/download/kantara-mobile-assurance-statement/

[c2bo]

WG discussion: Go with option 2, signal a wallet attestation by credential type without any special treatment from a protocol level initially. UX needs to be dealt with on ecosystem level via credential type

[peppelinux]

as previously mentioned in my comments, I fully support option 2

[paulbastian]

After discussion with @c2bo and @tplooker my thoughts are:

• I see a lot of potential trouble if we entirely handle wallet attestation as a regular credential
  • I expect wallet providers to fuck up implementations and display this data as a regular credential in Presentation Requests
• therefore, I recommend to have a dedicated top-level parameter for wallet attestation in Auth Request, this makes a clear separation and allows for easy UI implementation instead of filtering the presentation definition
  • filtering the presentation_definition will be challenging and cumbersome, especially if wallet attestation types may change or schemas get updated over time
• this is also right from a logical separation, just as we moved transaction_data out from presentation_definition, because presentation_definition is about the data that RP wants, but wallet attestation is not about data but about wallet authenticity
• similarly, the Auth Response should contain the wallet attestation in a dedicated top-level parameter, this would also work easily with Browser API in my thinking

[ssanchocanela]

Hi @paulbastian, if we talk about EUWI Wallet, there is a certification process that includes the functional certification for protocols and interfaces, back-up, PID and EAAs lifecycle management, activation... everything. So, those potential troubles coming from a wrong implementation SHALL not happen.

[paulbastian]

@ssanchocanela I expect that the wallet attestation credential type and shema may change over time, posting constant challenges for wallet implementers to do correct filtering of the presentation_definition. If the filtering dies not work, this leads to confusion of the holder, as they cannot understand the technical details of a wallet attestation. Certification may help, but the question is what parts will be certified and not all of the world is using eIDAS compliance tests.

@Sakurann what was the reason to remove transaction data from presentation_definition?

[alenhorvat]

Should we distinguish between

• key/device attestation
• authentication

Key/Device attestation Today, x509 certificates that attest quality of a public key are part of the digital signature "metadata" (x5c header in JWS).

IMO, both wallet (instance) and public key attestation fall in the same category, hence they should be part of the signature metadata. Namely, wallet instance attestation is equivalent to a QESCD root certificate, and key attestation (if used) would be a certificated signed by the QESCD root certificate.

Requesting/presenting them should be defined as part of the signature profile.

(Mutual) Authentication Note that this is different from (mutual) authentication as mentioned above (https://github.com/openid/OpenID4VP/issues/141#issuecomment-2237090978). But same applies for key/device attestation.

[c2bo]

Decided to postpone the PR a bit to focus on the other (more critical) issues/PRs targeted for 1.0.