01:50:45 RRSAgent has joined #dc-threats-iii 01:50:49 logging to https://www.w3.org/2025/11/12-dc-threats-iii-irc 01:50:49 RRSAgent, do not leave 01:50:50 RRSAgent, this meeting spans midnight 01:50:50 RRSAgent, make logs public 01:50:52 Meeting: Mitigate Threats for Digital Credentials API: Episode III - Revenge of the Wallet 01:50:52 Chair: Simone Onofri, Amir Sharif, Zahra Ebadi Ansaroudi 01:50:52 Agenda: https://github.com/w3c/tpac2025-breakouts/issues/45 01:50:52 Zakim has joined #dc-threats-iii 01:50:53 Zakim, clear agenda 01:50:53 agenda cleared 01:50:53 Zakim, agenda+ Pick a scribe 01:50:53 agendum 1 added 01:50:54 Zakim, agenda+ Reminders: code of conduct, health policies, recorded session policy 01:50:56 agendum 2 added 01:50:56 Zakim, agenda+ Goal of this session 01:50:56 agendum 3 added 01:50:56 Zakim, agenda+ Discussion 01:50:57 agendum 4 added 01:50:57 Zakim, agenda+ Next steps / where discussion continues 01:50:58 agendum 5 added 01:50:58 Zakim, agenda+ Adjourn / Use IRC command: Zakim, end meeting 01:50:58 agendum 6 added 01:50:59 breakout-bot has left #dc-threats-iii 02:14:30 simone has joined #dc-threats-iii 02:15:02 Amirsh has joined #dc-threats-iii 02:15:55 smcgruer_[EST] has joined #dc-threats-iii 02:16:01 present+ 02:16:15 KevinDean has joined #dc-threats-iii 02:17:16 JoeAndrieu has joined #dc-threats-iii 02:17:29 denkeni has joined #dc-threats-iii 02:17:37 Simone: @@@ 02:17:37 Amir: together with Zahra, we're going to talk about threats to DC API 02:17:41 ... some background about ourself 02:17:50 hsano has joined #dc-threats-iii 02:17:57 present+ 02:18:29 present+ 02:18:31 christianliebel has joined #dc-threats-iii 02:18:47 ... working for FBK, a research center in italy for cyber security with different focuses, and we're working on identity management, on different programs also with the italian government related to digital credentials issued by government, in particular on the wallet and italian technical specification 02:21:35 ... the DC API flow, and a user would like to access a credential on a website/verifier. the verifier shows a prompt, then the browser, then the wallet, the user can select the credentials (it is credential-centered), then wallet and browser prepare and send the presentation, for the verification 02:22:14 present+ 02:22:24 ... in our analysis we identified some key questions e.g., Malicious Wallet and Trust 02:22:53 ... first question is: which are the trust relationship between Issuer/Wallet... this should established at which level of the architecture? 02:23:38 Lee: it depends on the meaning on wallet trust 02:23:38 Amir: how the issuer can be sure they are issuing the credentials to a specific wallet 02:23:44 Lee: it is complex 02:23:46 ErikAnderson has joined #dc-threats-iii 02:23:48 hsano has joined #dc-threats-iii 02:24:05 ... there are multiple ways 02:24:11 present+ 02:25:28 ... OID4VCI has some ways, the @@ mode the user can start from DMV and they want to issue a credential to a user, e.g., driving licence, the credentials has a token to be exchanged, and there is an interactive protocol to define. Then we have also wallet attestation, to define trusted wallets 02:25:53 manu_ has joined #dc-threats-iii 02:26:14 DP has joined #dc-threats-iii 02:26:33 ... there is a problem with this mechanism. first mode is when the wallet don't send attestation, but if there is a non-authenticated way, this can be an issue 02:26:40 ... in this flow there is no session 02:26:42 camille has joined #dc-threats-iii 02:26:53 ... but there is always a part of attestation also on presentation 02:27:50 Amir: essentialy it is possible to use wallet attestation to authenticate the wallet. one question we have is that at least in EU context, you have the information of the wallet and a way to identify. in this case to we need to identify the origin? 02:27:50 q+ just to clarify that this means that no, trust for issuance is not part of the DC API itself, its part of whatever underlying protocol is being talked over the DC API? 02:28:07 q- 02:28:07 q- just 02:28:07 q+ to clarify that this means that no, trust for issuance is not part of the DC API itself, its part of whatever underlying protocol is being talked over the DC API? 02:28:32 Lee: in general, you need it 02:28:32 manu_ has joined #dc-threats-iii 02:28:38 q? 02:28:38 q? 02:28:43 q+ 02:29:06 ... scenario is: first you have to install a malicious wallet, that has no way to be attested 02:29:32 present+ 02:29:33 q+ 02:29:42 Tim: this is similar to passkey 02:30:02 Lee: in this case the malicious wallet is a proxy 02:30:04 wseltzer has joined #dc-threats-iii 02:30:35 ... a solution is passing a random challenge, secret from the wallet, and it is used by the OS 02:30:47 ewooton has joined #dc-threats-iii 02:30:53 ... the wallet passes to the attestation server, the origin is the package name 02:30:58 ... matching it 02:31:21 ack smc 02:31:21 smcgruer_[EST], you wanted to clarify that this means that no, trust for issuance is not part of the DC API itself, its part of whatever underlying protocol is being talked over 02:31:25 ... the DC API? 02:31:34 SMC: trust is at the DC API or at the protocol level? 02:31:39 q? 02:31:52 Lee: DC API in this case 02:32:17 Manu: one of the concern is that to use the wallet attestation to limit the wallets to be used in the particular user 02:32:33 ... what it the difference? e.g., you don't have browser attestation 02:32:44 akc manu 02:32:46 ack manu 02:33:00 ... what is the difference between the browser and the wallet? 02:33:06 Lee: attestation is optional 02:33:08 q+ on rate limit of attestation server 02:33:17 ... it is an additional feature 02:33:28 ... like a passkey manager 02:33:43 q+ to ask why no pushback if we don't do this for passkeys/browsers? 02:33:44 q? 02:34:14 JoelA has joined #dc-threats-iii 02:34:28 q+ 02:34:36 Amir: I can add also that in the EU context, the wallet needs to trust the issuer 02:34:53 ... and it is about trustworthiness 02:35:03 JoeAndrieu has joined #dc-threats-iii 02:36:31 Lee: the scenario is having just the wallet 02:36:37 ... compromised 02:36:40 q+ to ask if the attestation from a legal person 02:38:04 ack sim 02:38:17 tantek-projector has joined #dc-threats-iii 02:38:18 q? 02:38:21 RRSAgent, pointer 02:38:21 See https://www.w3.org/2025/11/12-dc-threats-iii-irc#T02-38-21 02:39:01 q? 02:39:27 Mohaned: this can be optional, and custom scheme it is worst 02:39:55 Lee: Google wallet is also used by gov, like Apple one. In this case standards can help solving it 02:40:09 Tim: any wallet can have a direct integration 02:40:10 q? 02:40:14 ack den 02:40:14 denkeni, you wanted to comment on rate limit of attestation server 02:40:32 denkeni: we're thinking on a while, with a collaboration of platforms and attestation servers 02:40:57 ... and have an integrity check with Google, with specific keys 02:41:24 ... this can also a way to interact with different issuers and verifiers, an attestation server can work of this effort 02:41:30 Lee: this is something only on the issuer side 02:41:46 ... but we don't present an integrity check 02:42:15 ... the way in which is today is like issuance a digital credentials, an interation of it 02:42:44 Tim: but you cannot contain a statement by yourself 02:43:13 YY has joined #dc-threats-iii 02:43:39 Lee: this is a pattern similar to some use cases of WebAuthn 02:44:21 denkeni: it is also something that is done at App Store/Play Store level 02:44:29 Lee: there is no integration for this aspect 02:44:54 JoeAndrieu has joined #dc-threats-iii 02:45:11 mouri has joined #dc-threats-iii 02:45:17 denkeni: on EU level is something made on the wallet server 02:45:17 Lee: it is using OS integrity check, then attesting itself 02:45:23 1? 02:45:25 q? 02:45:53 ... the flipside is that the attestation must the done for each issuer, and we deprecated SafetyNet 02:46:02 ... this is a reasonable compromise 02:46:11 Tim: a lightway way to do that 02:46:55 ... the challenge it is to make it fomr wallet 02:47:08 Nina: the website is interested that you are verified 02:47:14 ack menu 02:47:21 manu: it is fundamentally a bad idea 02:47:30 ... but I understand is a gov requirement 02:47:44 personal opinions, +1 to manu 02:48:07 ... i think W3C and that if we think it is bad idea, W3C can make a statement about that, as we're not using attestation 02:48:11 that really could break wallet interoperability in the future 02:49:02 manu: if a gov asks for a backdoor, we shound not do 02:49:02 Lee: this is done now at protocol level, not on the API, but this is in the EU law 02:49:31 ... this is a similar discussion to passkey providers that we decided to not attest, made a tradeoff 02:49:46 ... some actors are not using passkey because of that 02:50:03 Erick: this can hinder a new player to come in 02:50:07 ack Erik 02:50:16 ack manu 02:50:16 manu_, you wanted to ask why no pushback if we don't do this for passkeys/browsers? 02:50:39 Lee: we worked on wallet certification with FIDO 02:51:11 ... FIDO is working on the certification scheme, and anyone can be certified 02:51:32 Tim: this is a basic layer and anyone can be certified 02:51:50 ... DC API is just using the protocol 02:53:03 Nina: for gov the wallet must respect this 02:53:05 q? 02:53:33 ack Joe 02:53:34 JoeAndrieu, you wanted to ask if the attestation from a legal person 02:53:56 Joe: it is a bad idea but which is the legal entity involved? 02:54:50 ... so maybe this is another level of indirection 02:56:20 Lee: this can be tracked down for attestation, and an attacker with an official legal entity 02:56:34 JoeAndrieu has joined #dc-threats-iii 02:58:06 Topic: Methodology 02:58:06 Zahra: TM is the process of defining system, then threats, and how to response to them 02:58:23 ... we used the 4 questions shostack framework 02:59:11 ... we also used the ontology from NIST SP 800-115 02:59:45 [slides: https://docs.google.com/presentation/d/1ZGXgpmVbKjaES_R5XnfAWPan3cHRrNkwv8JEz-XSGB0/edit?slide=id.g3a0863e1392_0_0#slide=id.g3a0863e1392_0_0] 02:59:57 YY has joined #dc-threats-iii 02:59:58 ... for the threats we used STRIDE 03:00:26 Amirsh has joined #dc-threats-iii 03:00:39 ... in our model, we have entitites (e.g., UA, CM, Wallet, RP, RS), data flows (same device, cross-device) 03:01:09 ... which uses FIDO CTAP 2.2 03:01:25 ... then we have the swimlanes 03:01:33 ... for same and cross device 03:01:49 ... highlighting the boundaries 03:01:57 ... of course we have also some assumptions 03:02:21 ... UA mediation, CM mediation, the interaction channel, and the transport security 03:02:40 q? 03:03:04 ... what can be considered in the scope? 03:03:19 q+ to name the threat 03:03:35 Lee: OS and CTAP is OOS, this is good 03:04:27 Simone: we can also identity the bad effect if assumptions is violated 03:04:28 q+ to ask if there is already a threat model for CTAP/hybrid? 03:04:32 q? 03:04:50 ... CTAP can be a separate excerise 03:05:02 ... we have also a formal verification of DC API And CTAP 03:05:03 q? 03:05:09 q- 03:05:14 ... you can reference it 03:05:19 q? 03:05:43 rene has joined #dc-threats-iii 03:05:58 Joe: one of the way we're working in the Threat Modeling Guide, is having different "dependency threats", e.g., we have some dependancy on them 03:06:10 ... this is the difference on something we know but we have OOS 03:06:18 Lee: we don't check how TLS works 03:06:27 q? 03:06:29 ack joe 03:06:29 JoeAndrieu, you wanted to name the threat 03:06:49 Zahra: we have also primary assets 03:07:44 ... then we worked mainly on the presentation flow 03:08:43 ... using different zones to locate the threats 03:08:51 ... in the cross-device flow, we have different zones 03:09:14 ... then we mapped the assets on the zones 03:09:27 q? 03:09:53 ... then we used threat categories, attack scenarios, affecrted assets and understanding mitigations 03:10:19 ... we identified a side channel attack 03:11:40 Lee: DC API never knows about the credentials 03:11:42 ErikAnderson has joined #dc-threats-iii 03:11:49 Mohamed: but you can have faster responses 03:11:57 ... probabilistic attacks 03:13:14 q+ 03:14:07 Elan: we should measure it 03:14:31 Lee: @@ 03:14:53 ... you can send different queries distinguishing 03:14:58 Stephen: this is an attack 03:15:02 ... we've seen it 03:15:26 ... but probably we can also levarage on something done for WebAuthn 03:16:11 ... the idea was to design to avoid this threat 03:16:38 Zahra: API Flooding 03:16:52 Lee: we can add rate limiting like with WebAuthn 03:17:03 ... and transient activation 03:17:52 Zahra: DC API moves threats from the UI boundaries, solving some threats but creating new one 03:18:02 q? 03:18:14 ack smc 03:18:16 q? 03:19:20 RRSAgent, draft minutes 03:19:21 I have made the request to generate https://www.w3.org/2025/11/12-dc-threats-iii-minutes.html simone 03:26:12 Core8754 has joined #dc-threats-iii 03:29:42 JoeAndrieu has joined #dc-threats-iii 04:48:49 manu_ has joined #dc-threats-iii 05:51:25 manu_ has joined #dc-threats-iii 05:51:50 manu_ has joined #dc-threats-iii 06:01:07 manu_ has joined #dc-threats-iii 06:08:28 manu_ has joined #dc-threats-iii 06:08:45 manu_ has joined #dc-threats-iii 06:12:35 manu_ has joined #dc-threats-iii 06:16:47 manu_ has joined #dc-threats-iii 06:20:31 manu_ has joined #dc-threats-iii 07:05:45 tantek-projector has left #dc-threats-iii 13:45:58 tidoust has joined #dc-threats-iii 13:46:02 RRSAgent, bye 13:46:02 I see no action items