Meeting minutes
simone: layer diagram, with credentials especially at layer 3
… with layer 4 as website/applications, and layer 5 as trust/governance
simone: request from a verifier/website for a credential presentation
… focus on request content/request credential/present credential/grant access steps.
… look for approaches that are safer and more private than others
… for use case of requesting a visa, scanning a passport picture and send over the wire to the website (how it's done today)
… 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
… threat model on Presenting Credentials on the Web, including approaches around custom schemes (which has potential attacks), qr codes, and browser API
… 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
… 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)
… cross-device demo, including scanning a QR code displayed on the laptop onto the user's phone
… lots of authorization steps for the user before sharing
… should notify the user if something bad is happening
… could have a trust-list managed by the local government, or consumed by the wallet
<tara> npdoty: there are several threats without known mitigation, e.g., websites asking for too much info, sites using this info for cross-site tracking
torgo: risk of websites learning which credentials you have, or where they come from, in order to learn details about your identity
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.
credential considerations risks/mitigations from npdoty: https://
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.
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.
tim: competing with a bad model that exists today with custom schemes
… can reduce the risk of phishing via custom schemes, even if we haven't solved the other things yet
… 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.
slides/presentation from Tim: https://
simone: already have the bad model of sending images of documents around the web
… and this information is verified, rather than just a stolen image
<DKA> Nick: some risks - is the user informed - make sure users are promped with the relevant information - also legal mechanisms to hold them responsible...
<DKA> ... things we can put into permission dialogs... things that can go into controls...
<DKA> ... 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...
<DKA> ... someone [a 3rd party] who has validated ...
<DKA> ... could address accountability and rampant over-asking
<DKA> ... making sure we have hooks for trust ... and that web sites have to explain what they are doing....
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
… make it useful for some use cases but inconvenient for others
simone: try to avoid repeated prompts or other abuse of prompts in spamming users
<benvds> me raises hand
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.
[important, agreement, on genuine work on collaboration]
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
protect user's privacy because it should always be safe to visit a web page
… need to be more careful to preserve the promise of user centricity and priority of constituencies for the web (compared to some native platforms)
… 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
… but it's overreach, and it's something the web shouldn't be enabling. focus on the use cases that helps user priorities.
… I'm here to help things progress!
… wanted to reinforce the message from the council, that the group should take concerns from objection into account during development
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
… especially given, per npdoty, the ability for regulators to help address abuse
Ian: would love to hear more mitigation strategies. in the payments context, potential authentication through digital credentials
… don't want digital credentials to supplant FIDO-style anonymous authentication use cases
… mitigation strategy is to help the user lean in the less-identifying direction
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
simone: how to balance the two user agents (wallet and browser)
simone: ways to inform the user that something is happening at the wallet level
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.
… could try to influence other standards to justify our assumptions as part of the larger ecosystem
<DKA> Nick: I think it's useful to talk about responsibilities... not everything handled by the browser API...
<Ian> npdoty: It's useful to talk about responsibilities, and not everything would be handled by the browser API.
<DKA> ... but we should be clear of what's being addressed where.
<DKA> ... other model that some people have assumed is true is that the web site is supposed to get consent...
<DKA> ... 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
<DKA> ... need to design APIs in a different way because all the context info will need to pass to the wallet.
<DKA> [or we could end up with worst case - consent being asked twice which would be confusing at best]
<DKA> [note that Tim disagrees and thinks the context is being passed in the request]
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
simone: thanks all for considering the threats and mitigations
<Ian> [Thanks all!]
simone: maybe next time we can coordinate with Security Interest Group, Privacy Working Group and Fed ID Working Group
… we are all on the same page for this to happen in the best way that is possible