-
Notifications
You must be signed in to change notification settings - Fork 20
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
Comments
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. |
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. |
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. |
@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).
@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. |
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. |
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?
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 :) |
@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.
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.
thank you ❤️ |
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. |
Interestingly the eIDAS requirement is in direct contradiction to the W3C VCDM which states
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? |
@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. |
@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 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. |
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 |
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. |
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.
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. |
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. |
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. |
@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. |
Agree, the lifecycles are probably different, so this is not a good choice. |
@ve7jtb Whats your opinion? |
Discussion within IDunion summarized:
|
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. |
The requirement for mutual authentication stems from mandates outlined below:
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. 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. |
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. |
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. |
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. 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. |
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. |
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? |
I prefer option 2 too. |
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. |
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. |
Discussed in a WG call:
|
Here is a mobile assurance statement that could be used in the way intended https://kantarainitiative.org/download/kantara-mobile-assurance-statement/ |
WG discussion: |
as previously mentioned in my comments, I fully support option 2 |
After discussion with @c2bo and @tplooker my thoughts are:
|
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. |
@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? |
Should we distinguish between
Key/Device attestation 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 |
Decided to postpone the PR a bit to focus on the other (more critical) issues/PRs targeted for 1.0. |
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. |
discussed during a WG call: 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). |
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. |
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 |
It's the same :) |
In OpenID we differentiate those, see latest discussions in OpenID4VCI. |
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." 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. |
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. |
My thoughts on the wallet attestation and how to request/present it:
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:
|
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] |
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:
vp_token
. This option would not require any change to the spec.The text was updated successfully, but these errors were encountered: