2024-05-20 (A Call)

Organizer: Tim Cappalli

Scribe: Ben

Agenda

• Administrivia
  • REMINDER: WICG Digital Credentials F2F on 6/21/24 in Mountain View (co-located with joint Fed ID CG/WG meeting on 6/20/24)
• Intros from new folks
• Updates from incubation
• Anyone from Chromium or WebKit have any updates?
• Anyone prototyping with their wallet or verifier?
• Any updates from the OID4VP workstream in OIDF DCP WG?
• Federated Identity WG charter update
• Continued discussion
  • Wallet-provided nonce (#92)
    • Torsten - good to close this?
  • Limit access to the API based on known allow listed origins #59
    • Can we close this?
• New discussion
  • Privacy properties #115
    • Restart registry discussion?
  • Explainer: no mention of what security and privacy properties of a request are desirable #108
• Mozilla Standards Position
  • Slack discussion: https://w3ccommunity.slack.com/archives/C05UG0EJUDB/p1715738471025739
• TPAC Planning
• AOB

Attendees

• Zacharias Törnblom (SUNET, SeamlessAccess)
• Wendy Seltzer (Tucows)
• Heather Flanagan (Spherical Cow Consulting)
• Benjamin VanderSloot (Mozilla)
• Hicham Lozi (Apple)
• Nick Doty (CDT)
• Joseph Heenan (Authlete / OIDF)
• Chris Needham (BBC)
• Hiroyuki Sano (Sony Group)
• Tim Cappalli (Okta)
• Tom Jones

Notes

Administrivia

Tim covers administrivia

Registration form for face to face coming - https://forms.gle/7vBBGVEQ52ffioWu5

Remote option available

Dates are final so book travel

Intros from new folks

No new introductions

Anyone from Chromium or WebKit have any updates?

No updates on browser implementation

Fed ID WG Charter Updates

Update on the charter: Simone posted about this in the Slack just hours ago https://github.com/w3c/strategy/issues/450#issuecomment-2118895191 posted in Zoom chat now.

Open time for comment, but we will have time next meeting

Wallet-provided nonce (#92)

Torsten not present so we will not discuss Wallet-provided nonce (#92)

Limit access to the API based on known allow listed origins #59 discussion

No further discussion on maintaining this. Chrome has posted about how they intend to handle abuse

Summary from last discussion is in the issue

Sam: confirms Chrome’s position as allowlist is an option of last resort

Nick: Issue was allowlist from Kyle initially, but expanded to something more general. May have consensus on allowlist not being the right solution, but we should not close the path of the more general cases like trustmarks

Ben: agree consensus on no allow list, but should have other issues for the more nuanced alternatives

Sam: We currently allowlist certain request types (like age bracket, which reveals only the age bracket and the issuer information, which is pretty high entropy), but not origins

Tim: Updating the issue. Perhaps this ties into Simone’s issue on threat modelling.

Going to link the issue and close it

Privacy properties #115

Tim: seems like a reasonable summary of the issues

Orie: supportive of documenting threat models early

Nick: Question on earlier point, sounds like there is less interest in origin allowlist, but maybe there would be technical requirements from some jurisdictions. Do we expect the verifier to perform that filtering?

Paolo: Am aware of EU requirements. How this is done is unclear

Nick: WHat should we do, do we have an issue for this?

Joseph: we think we can handle this at the protocol layer

Paolo: We think we can do this at the protocol layer.

Nick: I thought that discussion was about the wallet authentication, not verifier registration

Tim: API provides context

Hicham: I thought it was about wallet instance authentication. We should have that concern here, not just at the protocol side

Tim: Wallet authentication will be at issuance and will therefore be out for the part of the API we are cooking up now

Paolo: Clarifying requirements of the legislation: revocation ???, relying party must be registered and authenticated in order to do the presentation.

Discussion was here: https://github.com/WICG/digital-credentials/issues/81

Tim: in passkeys the verifier can get all of the information afterward and decides what to do with it afterward. So the information is provided

Hicham: Q: why is the legislation mandating authentication at presentment? Issuance is enough

Paolo: it is hard to give you a precise answer. It was a negotiation between multiple parties. Prevent sharing of data with the wrong parties. The authentication is not every “get”- it can be sticky

Hicham: It is clear why we need the right relying party. But authentication the wallet at presentment is less clear. It would be good to have a concrete reason

Paolo: Revocation is a good reason. And have the RP to be certain it is dealing with a valid EUDI wallet, without external trust.

Tim: Isn’t revocation of a credential independent of the wallet? Isn’t that also handled out of band?

Orie: Maybe! It depends on the credential format. VCs have that. It is assumed the verifier would have to check the status of a credential- using per-format checks. Both CRL and OCSP styles exist.

Tim: Does regulation specify either of those models?

Paolo: revocation of instances. Wallets can be revoked by the wallet publishers. This is an independent behavior. We also tried chaining revocation, but it was complicated

Tim: Hicham, please post your specific questions

Nick: I led us down this path, but didn’t get to my point. We may need joint work on privacy and threat modelling including horizontal review. Into Zoom Chat: https://github.com/w3c/strategy/issues/458. A joint deliverable with other groups would be most appropriate. Some question may be out of scope of this API design, however are important on the impact of the entire feature.

Tim: related to FedID

Heather: ack

Tim: lots of reading. Let’s put them on the B call and get to them then

Tim: we may need to know which properties are needed for a protocol’s inclusion in a registry. And think about how to create this registry. Not blocking, but parallel is good.

Ben: +1, sooner than later

Tim: How to do this

Orie: There is a formal process for the registry.

Orie: Looping back to Sam. The idea is to make it hard for verifiers to make deep, identifying, and ??? request to the API. Is this the same type of allowlisting that you were talking about earlier? Is this the protocol or data being requested type of registry.

Sam: registry of protocols. E.g. openid4vp. Not the request types that Chrome uses now: eg age of majority.

Tom: we need to put the registry of types above that of protocols

Sam: Spatial confusion. Above? Two layers- openid4vp layer and the presentation exchange layer.

Tom: You need to know what stuff you can request before you pick the protocol

Sam: Verifier will know and decide, then the browser has it done

Tom: This is hard on the verifier

Sam: This is status quo

Tim: Verifier needs to craft a response based on the request

Orie: restating… I’m requesting this mDoc thing or that mDoc thing, but they are over the protocol. But blocking some types of things would be useful

Ben: Blocking things would be useful, but there are concerns about the open world of things to be requested.

Sam: Friction is the tool to handle the open world. Put the types that have lower friction in a list. Currently just our allowlist

Orie: Issuers that can satisfy these request types, this could be constrained to origin as well. We don’t know the weird cases. And the dynamic behavior of the registry’s growth makes things more complicated.

Sam: We would put any request type not in the registry into a fallback “high friction” flow

Hicham: Registry of protocols is familiar. First time thinking of request types. Seems hard to achieve, and don’t know why we would do this.

Sam: you seem to understand, you disagree?

Hicham: If the browser knows the protocol, why would we need to change the experience for the user?

Orie: We don’t need to, but we can make it harder for users to incidentally expose private information. Blind forwarding of requests is one way to do things. Other browsers could flag things.

Sam: spec or UA choice?

Ben: UI can be UA choice, but we should try to understand what the things that are that we treat differently, to ensure consistent treatment across browsers.

Hicham: Not reasonable to have a list of all “vaccine identifier” lists. I doubt this will work.

Tim: Next call is in 2 weeks. Next B call is in 3 weeks.

How many will be in person (3 hands rise).

Open floor!

Hicham: ISO meeting overlaps with F2F.

Thanks everyone!