10:20:19 RRSAgent has joined #credential-threats 10:20:23 logging to https://www.w3.org/2025/03/26-credential-threats-irc 10:20:23 RRSAgent, do not leave 10:20:24 RRSAgent, this meeting spans midnight 10:20:24 RRSAgent, make logs public 10:20:25 Meeting: Mitigate Threats for Digital Credentials API: Episode II - Attack of... 10:20:25 Chair: Simone Onofri 10:20:25 Agenda: https://github.com/w3c/breakouts-day-2025/issues/17 10:20:25 Zakim has joined #credential-threats 10:20:26 Zakim, clear agenda 10:20:26 agenda cleared 10:20:26 Zakim, agenda+ Pick a scribe 10:20:28 agendum 1 added 10:20:28 Zakim, agenda+ Reminders: code of conduct, health policies, recorded session policy 10:20:28 agendum 2 added 10:20:28 Zakim, agenda+ Goal of this session 10:20:29 agendum 3 added 10:20:29 Zakim, agenda+ Discussion 10:20:29 agendum 4 added 10:20:29 Zakim, agenda+ Next steps / where discussion continues 10:20:31 agendum 5 added 10:20:31 Zakim, agenda+ Adjourn / Use IRC command: Zakim, end meeting 10:20:31 agendum 6 added 10:20:31 breakout-bot has left #credential-threats 10:27:17 tidoust has joined #credential-threats 13:58:07 Tara8 has joined #credential-threats 14:01:28 pchampin has joined #credential-threats 14:07:07 tara4 has joined #credential-threats 14:07:21 npdoty has joined #credential-threats 14:08:04 tara has joined #credential-threats 14:08:11 unextro3 has joined #credential-threats 14:08:20 rrsagent, log? 14:08:20 I'm logging. Sorry, nothing found for 'log' 14:08:25 tara4 has left #credential-threats 14:08:44 scribe: npdoty 14:09:13 simone: layer diagram, with credentials especially at layer 3 14:09:22 unextro has joined #credential-threats 14:09:23 ... with layer 4 as website/applications, and layer 5 as trust/governance 14:09:30 unextro3 has left #credential-threats 14:09:44 MShea has joined #credential-threats 14:10:05 simone: request from a verifier/website for a credential presentation 14:10:52 ... focus on request content/request credential/present credential/grant access steps. 14:11:16 ... look for approaches that are safer and more private than others 14:12:53 ... for use case of requesting a visa, scanning a passport picture and send over the wire to the website (how it's done today) 14:13:40 ... risks including image file that can be copied around, third-parties might also have access to it, using a physical credential that isn't suited to digital presentation 14:15:08 ... threat model on Presenting Credentials on the Web, including approaches around custom schemes (which has potential attacks), qr codes, and browser API 14:17:57 ... security risks of access by the browser to what is being presented. a general condition that the user needs to trust their own browser, wallet and device software 14:20:20 ... showing demo from Tim Cappalli, including browser permission prompt, credential selector dialog (showing which origin is asking, and the data that would be shared), and a dialog from the wallet (including privacy policy link and scary warning box) 14:21:45 ... cross-device demo, including scanning a QR code displayed on the laptop onto the user's phone 14:22:29 ... lots of authorization steps for the user before sharing 14:23:36 ... should notify the user if something bad is happening 14:23:49 ... could have a trust-list managed by the local government, or consumed by the wallet 14:26:10 npdoty: there are several threats without known mitigation, e.g., websites asking for too much info, sites using this info for cross-site tracking 14:27:17 torgo: risk of websites learning which credentials you have, or where they come from, in order to learn details about your identity 14:28:26 torgo: working on TAG finding. "the web must never demand your papers". context is that the formal objection was overruled by the council in order for the work to happen. but the finding is to reinforce that the issues need to be addressed, and potential harm to society. 14:29:10 credential considerations risks/mitigations from npdoty: https://github.com/w3c/credential-considerations/blob/main/credentials-considerations.md 14:30:48 torgo: in travel planning, already providing credential information to japanese government website. if an API were provided, wouldn't the government request that? when that is implemented, important that the user's data is protected from that form, so that user is in control of which credential is presented. 14:32:14 tim: two user agents at play, both the browser and the wallet. wallet is ultimately responsible for protecting the user's information. browser API won't reveal what credentials you have. separation of responsibilities: wallet is responsible for capturing consent, while browser just captures permission to access the wallet. 14:32:32 tim: competing with a bad model that exists today with custom schemes 14:32:50 ... can reduce the risk of phishing via custom schemes, even if we haven't solved the other things yet 14:33:29 ... a lot of bad things already happening, shouldn't wait for a complete solution. otherwise people will continue using custom schemes and there won't be a way to protect users in future versions of the API. 14:35:01 slides/presentation from Tim: https://drive.google.com/file/d/1QjTX9OLfuIY96ahMpRX7Hq6Kd6A7VyFG/view 14:35:16 simone: already have the bad model of sending images of documents around the web 14:35:44 ... and this information is verified, rather than just a stolen image 14:36:27 DKA has joined #credential-threats 14:36:41 Present+ Dan_Appeluist 14:36:51 benvds has joined #credential-threats 14:37:10 Nick: some risks - is the user informed - make sure users are promped with the relevant information - also legal mechanisms to hold them responsible... 14:37:28 ... things we can put into permission dialogs... things that can go into controls... 14:37:59 ... another class of problems: users don't know whether to trust or if a request is appropriate - there might be a need for trust lists... 14:38:11 ... someone [a 3rd party] who has validated ... 14:38:31 ... could address accountability and rampant over-asking 14:38:50 ... making sure we have hooks for trust ... and that web sites have to explain what they are doing.... 14:38:53 q+ 14:40:08 DKA: time-based requirements so that the API is inconvenient to be used for certain cases that it's not intended for, like site login/authentication. is that a potential mitigation -- can't be invoked by a particular origin more than once in a particular time period 14:40:15 ... make it useful for some use cases but inconvenient for others 14:41:55 q+ 14:41:55 simone: try to avoid repeated prompts or other abuse of prompts in spamming users 14:42:04 me raises hand 14:42:15 q+ benvds 14:42:53 ack DKA 14:43:41 DKA: taking a step back, reassure Tim and the WG that everyone is on the same side. we all want to see this happen, which is why we are talking about threats. not trying to put stop energy here, but how can we make this work in a way that also supports the goals of the web. 14:44:46 [important, agreement, on genuine work on collaboration] 14:46:05 DKA: on powerful APIs, have had many debates about adding sensitive APIs and the motivation that it's necessary in order for the success of the platform. TAG has tried to balance this: embrace the new and enabling new use cases AND what differentiates the web, as described in the ethical web principles, to make a positive impact on society and to 14:46:05 protect user's privacy because it should always be safe to visit a web page 14:46:45 ... need to be more careful to preserve the promise of user centricity and priority of constituencies for the web (compared to some native platforms) 14:47:24 ... and so to the question of authentication. every website might want to have the information on your passport/driver's license, because it helps me as a business 14:47:32 q+ 14:47:44 ... but it's overreach, and it's something the web shouldn't be enabling. focus on the use cases that helps user priorities. 14:48:21 ... I'm here to help things progress! 14:48:40 ... wanted to reinforce the message from the council, that the group should take concerns from objection into account during development 14:48:44 ack benvds 14:48:50 hsano has joined #credential-threats 14:48:52 Ian has joined #credential-threats 14:48:53 q+ Ian 14:49:53 benvds: threat and mitigations. model of different wallets. easy for a webpage to trigger a request, and browser could have a different sense of that based on whether it's an EU wallet with some protections, vs "wild west" approach 14:50:03 ... especially given, per npdoty, the ability for regulators to help address abuse 14:50:05 ack Ian 14:50:49 Ian: would love to hear more mitigation strategies. in the payments context, potential authentication through digital credentials 14:51:11 ... don't want digital credentials to supplant FIDO-style anonymous authentication use cases 14:51:24 ... mitigation strategy is to help the user lean in the less-identifying direction 14:52:22 tim: in order for the browser to help, the browser has to understand the request. any verifiable credential can be distributed over this api. Nick has opened issues on this distinction, whether we can classify the types of credentials and potential implications 14:53:27 simone: how to balance the two user agents (wallet and browser) 14:53:31 q+ 14:53:51 simone: ways to inform the user that something is happening at the wallet level 14:53:55 I have made the request to generate https://www.w3.org/2025/03/26-credential-threats-minutes.html Ian 14:54:51 ack simn 14:54:53 ack sim 14:55:39 simone: structure to security and privacy considerations sections. track the assumptions that we have, FedCM might be a useful model. can document the security assumptions that we have, like trusting the browser and the wallet. 14:55:59 ... could try to influence other standards to justify our assumptions as part of the larger ecosystem 14:56:34 Nick: I think it's useful to talk about responsibilities... not everything handled by the browser API... 14:56:35 npdoty: It's useful to talk about responsibilities, and not everything would be handled by the browser API. 14:56:47 ... but we should be clear of what's being addressed where. 14:57:13 ... other model that some people have assumed is true is that the web site is supposed to get consent... 14:57:33 ... we could be talking about "no consent needs to be handled by the web site" - but if it's handled by the waller side then we 14:57:50 ... need to design APIs in a different way because all the context info will need to pass to the wallet. 14:58:14 [or we could end up with worst case - consent being asked twice which would be confusing at best] 14:58:44 [note that Tim disagrees and thinks the context is being passed in the request] 14:59:16 I have made the request to generate https://www.w3.org/2025/03/26-credential-threats-minutes.html Ian 14:59:56 npdoty: we have occasionally heard from the OpenID4VP protocol design that maybe it would include purpose/context/explanation, but we have also heard them move away from it. so I think we should actually be clear about what assumptions we have 15:00:03 benvds has left #credential-threats 15:00:04 simone: thanks all for considering the threats and mitigations 15:00:16 [Thanks all!] 15:00:21 ... maybe next time we can coordinate with Security Interest Group, Privacy Working Group and Fed ID Working Group 15:00:30 ... we are all on the same page for this to happen in the best way that is possible 15:00:46 I have made the request to generate https://www.w3.org/2025/03/26-credential-threats-minutes.html Ian 16:03:11 zakim, bye 16:03:11 leaving. As of this point the attendees have been Dan_Appeluist 16:03:11 Zakim has left #credential-threats 16:03:13 rrsagent, bye 16:03:13 I see no action items