Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
tlodderstedt opened this issue Mar 29, 2024 · 57 comments

Comments

@tlodderstedt
Copy link
Collaborator

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
Copy link
Member

c2bo commented Mar 29, 2024

  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
Copy link
Collaborator

jogu commented Mar 29, 2024

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
Copy link
Contributor

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
Copy link
Member

@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
Copy link
Contributor

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
Copy link
Collaborator

jogu commented Mar 29, 2024

@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
Copy link
Member

@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 ❤️

@bc-pi
Copy link
Member

bc-pi commented Mar 29, 2024

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
Copy link
Contributor

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
Copy link
Contributor

paulbastian commented Mar 30, 2024

@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
Copy link
Contributor

@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
Copy link
Contributor

tplooker commented Mar 31, 2024

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
Copy link
Contributor

paulbastian commented Mar 31, 2024

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
Copy link
Contributor

tplooker commented Apr 1, 2024

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
Copy link
Collaborator

jogu commented Apr 1, 2024

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
Copy link
Collaborator Author

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
Copy link
Contributor

awoie commented Apr 15, 2024

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
Copy link
Member

peppelinux commented Apr 15, 2024

@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
Copy link
Contributor

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
Copy link
Contributor

@ve7jtb Whats your opinion?

@paulbastian
Copy link
Contributor

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
Copy link
Member

bc-pi commented Apr 26, 2024

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
Copy link

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
Copy link
Contributor

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
Copy link
Collaborator Author

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
Copy link

paolo-de-rosa commented May 14, 2024

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
Copy link
Collaborator

Sakurann commented May 29, 2024

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
Copy link
Member

peppelinux commented May 30, 2024

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
Copy link

I prefer option 2 too.

@jogu
Copy link
Collaborator

jogu commented Jul 30, 2024

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
Copy link

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
Copy link

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.

@danielfett danielfett assigned danielfett and unassigned danielfett Aug 22, 2024
@Sakurann
Copy link
Collaborator

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
Copy link

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

@c2bo
Copy link
Member

c2bo commented Aug 27, 2024

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
Copy link
Member

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

@paulbastian
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

@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
Copy link

alenhorvat commented Aug 29, 2024

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 (#141 (comment)).
But same applies for key/device attestation.

@c2bo
Copy link
Member

c2bo commented Sep 11, 2024

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

@David-Chadwick
Copy link
Contributor

As I said early on in this discussion, having wallet attestations for the verifier is something of a spurious requirement, but by implementing it as Option 2 we sort of acknowledge this. The verifier may or may not request it. A wallet may or may not possess it. This helps for global interworking where some wallets are certified and some are not, and some verifiers care about wallet attestations and some do not. So by requesting the wallet attestation as a normal credential in the presentation request we cater for all 4 possible scenarios, i.e. wallets with/without it and verifiers who want/don't want it. This seems like the best global solution.

@Sakurann
Copy link
Collaborator

discussed during a WG call:
would suggest separating the discussion on how to request a credential (just like any other credential vs dedicated header) to optimize UI and how to return the credential (just like any other credential vs dedicated header).

no rough consensus, yet, with potentially slight preference for dedicated header in the request and just-like-any-credential in the response

@c2bo
Copy link
Member

c2bo commented Oct 28, 2024

discussed during a WG call: would suggest separating the discussion on how to request a credential (just like any other credential vs dedicated header) to optimize UI and how to return the credential (just like any other credential vs dedicated header).

no rough consensus, yet, with potentially slight preference for dedicated header in the request and just-like-any-credential in the response

I don't think a dedicated header is a good option as it would directly break with DC Browser API. The alternative would imho be to have a dedicated parameter in the request (and response).

@Sakurann
Copy link
Collaborator

Sakurann commented Nov 4, 2024

discussed during IIW. the direction seems to be to add new top level parameters to request & response dedicated to wallet attestation. the reasoning being that wallet attestation should not be treated as a normal credential, for example because wallet would need to filter it out for credential selector in browser API. need to continue discussing in the WG.

@alenhorvat
Copy link

Public key attestations are already widely used today and there's a good support for them in JWT/JWS. (x5c header parameter)

@paulbastian
Copy link
Contributor

Public key attestations are already widely used today and there's a good support for them in JWT/JWS. (x5c header parameter)

This is not about key attestation, but wallet attestation

@alenhorvat
Copy link

alenhorvat commented Nov 5, 2024

It's the same :)
(key attestation is issued only to a wallet that meets all the requirements/checks; name is different, data model in both cases contains a public key + additional information about the security policies)

@paulbastian
Copy link
Contributor

It's the same :) (key attestation is issued only to a wallet that meets all the requirements/checks; name is different, data model in both cases contains a public key + additional information about the security policies)

In OpenID we differentiate those, see latest discussions in OpenID4VCI.

@martijnharing
Copy link

martijnharing commented Nov 6, 2024

I'm still strongly in favor of option 2.

Most importantly because otherwise we would be re-inventing the wheel. We already have a protocol that allows to request and send credentials with data elements that can be linked to a key to authenticate with during presentment of those credentials.

Making a special format for the response means that compared to treating the wallet attestation credential as a regular credential, we risk encountering a situation where the credential format the wallet intends to use for the credential itself doesn’t align with the format of the wallet’s attestation. We would need to decide what credential format is it based on, SD-JWT VC, mdoc, JWT, Anoncred etc. If the credential format that we choose does not match the one it is being used with, the wallet application, the underlying secure hardware, the issuance protocol, the issuer hardware, the verifier logic etc. There are also privacy considerations for credential presentment related to tracking which different solutions are being used / proposed for (single-use credentials, limited-use credentials, ZKP approaches etc) by mandating a credential format for wallet attestation this could mean that we are also preventing or limiting support for these kind of solutions.

Making a special parameter for the request means that we still need to integrate that with the DCQL, since you want to be able te say things like. "For credential a I need a wallet attestation, for credential b I do not."
A special request parameter means that we either need to define a way to request multiple different request formats (which is something we have solved as part of the DCQL) or we would only support a single format (which has issues as described in the previous paragraph).

Finally, it would mean that we need to normatively define what a "wallet attestation" is, what it attests to and what it doesn't attest to. As part of presentment of a credential, a lot of software and hardware components are involved. What exactly is and isn't part of the wallet attestation will likely not be the same for all implementations/ecosystems etc and the 'normal' credential may also contain some attestation information that could also be handled by a wallet attestation credential.

@David-Chadwick
Copy link
Contributor

David-Chadwick commented Nov 6, 2024

Treating a wallet attestation the same as every other credential is my favoured approach. It makes requesting and delivering the credential straight forward and does not require any changes to our protocols. Also I do not have a problem with this wallet attestation credential being displayed to the user like other credentials. It shows the user that they have a gold star approved wallet. It is quite common in real life to buy electrical appliances that have an electric safety approval certificate. So I think users will be quite happy to see that their wallet has an "EC approved wallet" credential.

@c2bo
Copy link
Member

c2bo commented Nov 7, 2024

My thoughts on the wallet attestation and how to request/present it:

  • We need to separate request / response - these are separate problems and I think in the discussion, we successfully started to distinguish between these
  • We should also separate UI and the processing aspects:
    • There is the issue of UI/UX: We need to deal with this a bit differently from a "normal" request -> we need consent, but a different kind of displays than you would present for a credential
    • How to present and verify the attestation: This is where things should be very similar to "normal" credential requests -> we need to create a PoP over a nonce etc.

The UI/UX aspects point towards not re-using DCQL/vp_token, whereas the processing (by wallet & RP) would/could benefit from re-using those to prevent somewhat redundant implementations.

Those thoughts brought me to liking the option that was brought up in the discussion on Tuesday quite a bit more:

  • Use DCQL and vp_token to convey request / response
  • Have a special request parameter that signals that a specific credential request is a wallet attestation identified via id within the credentials array in DCQL
  • Additionally, we would define a proposed/default wallet attestation data set & format in VCI (current PR) and reference this as the default option for the wallet attestation towards a RP.

@David-Chadwick
Copy link
Contributor

Yesterday I had discussions with Nishant Anand who is doing a PhD at UCL on Interdisciplinary aspects on digital identity systems governance. In particular we discussed how trust can be increased, because he has already determined that trust is eroded through the “black boxed” nature of governing eID systems. The proposal to display to users the wallet attestation as a mark of conformance to EC standards, should help to increase users trust in the overall system and in the downloaded wallet app in particular. I believe this approach strengthens the case for treating the wallet attestation in a very similar way to normal credentials, and certainly would be against hiding this credential from the user.

For those who would like to know more about this research, or who would like to participate through a one hour expert interview with Nishant, you can contact him at [email protected]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests