Skip to content

2024 06 03 Meeting Notes

Jump to bottom
Tim Cappalli edited this page Jun 4, 2024 · 1 revision

2024-06-03 (A Call)

Organizer: Tim Cappalli

Scribe: Helen Qin

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
  • FYI: joint work on rights-respecting digital credentials
  • TPAC: Which timeslot?
    • Monday 11:00-12:30
    • Monday 14:00-16:00
    • Tuesday 11:00-12:30
    • Tuesday: 14:00-16:00
    • Thursday: 11:00-12:30
    • Thursday: 14:00-16:00
    • Friday: 11:00-12:30
    • Friday: 14:00-16:00
  • Continued discussion
  • New discussion
    • Threat Modeling for Decentralized Identities (#115)
    • Should we have a common and interoperable definition of request types and their privacy properties? (#117)
  • TPAC Planning
  • AOB

Attendees

  • Tim Cappalli (Okta)
  • Ted Thibodeau (he/him) (OpenLink Software)
  • Benjamin VanderSloot (Mozilla)
  • Chris Needham (BBC)
  • Helen Qin (Google/Android)
  • Lee Campbell (Google/Android)
  • Rick Byers (Google/Chrome)
  • Hicham Lozi (Apple)
  • Manu Sporny (Digital B
  • Tom Jones
  • Heather Flanagan (Spherical Cow Consulting)
  • Nick Doty (CDT) - listening, mostly
  • Brian Campbell (Ping)
  • Hiroyuki Sano (Sony Group)

Notes

Administrivia

Tim: Reminder of the F2F meeting: registration form June F2F registration

Incubation updates

Sam: progress is being made

Manu: CA state released OpenCred. Planning on implementing the digital cred API in the summer. DHS announced requirements for decentralized identity requirements — they are tracking the digital credentials APIs. There’s a video of it.

Tom: reminder that this isn’t a government policy until it is in the federal registry

Sam: relationship of VCs & mdocs?

Manu: cannot comment on behalf of US policy. OpenCred will support everything, protocols and formats. Issuing in VC format for SVIP use cases but supports verifying many formats.

Tom: CA currently ship with mdoc dc cred and age verification cred. Complicated to present cred in person.

Tim: this group is scoped to the web platform presentation

Lee: OpenID group looks at both; ISO, too. Here we generally focus on the web presentation APIs. The in-person presentation problems do exist.

Manu: the convenience store is deploying TruAge. It’s the QR code and unlinkable. But this group is focusing on the digital credential web API. For in person, besides QR code also looking at connecting the person’s phone with an online process.

Tobias: successfully done integration around the API. Working e2e. Will try to provide some sample apps for playing around.

Tim: dcp working group?

Joseph: progress on various bits not particularly relevant to this group. Some profile updates to the web API profile as a pull request.

Federated Identity WG charter update

Heather: Charter update — in horizontal review. It hasn’t gone through any kind of vote yet.

FYI: joint work on rights-respecting digital credentials

Tim: PR 458: joint work on rights-respecting digital credentials. Just FYI a document on rights/privacy to the digital credential APIs / decentralized identities.

TPAC: Which timeslot?

Tim: TPAC which timeslot (in agenda)?

Will create a slack poll link

Hicham: prefer the time slot to be the sooner the better

Mozilla Standards Position

Rick: concerned with the same problems. Strategy is to address them proactively. Welcome people pointing out these problems so we can work on them in this group.

Benjamin VanderSloot: agreed this is not Mozilla saying don’t work on this at all. These are reasons Mozilla doesn’t feel comfortable shipping yet.

Rick: Is Mozilla fine with custom schemes being used as-is?

Ben: exploring warnings for custom schemes

Rick: Chrome is in a different position. Cannot credibly create warnings when we don’t have an alternative solution. Firefox can make a different decision.

Tobias: Good write up of risks, etc. Want to point out additional things to evaluate that weren’t explicitly specified in the doc. Without the web api and wallet provision, the fallback solution is IDV through uploading the physical copy of an ID and the risks of that. Was the analysis compared with OpenID with custom schemes or the manual IDV?

Ben: a holistic look

Lee: Is Mozilla recommending these alternatives then?

Ben: Photos and custom schemes are not ok, but are things that can work until we find a good solution

Hicham: We should be very careful with letting alternatives prosper while solving the problems. Hard to migrate. We should not just say that what’s out there is problematic without having an alternative.

Sam: How much of the analysis is done over-indexed on real world identity versus others like social logins?

Ben: Deeply involved in real world identity. Which seems to be the reason that this is moving so quickly?

Sam: Ack the regulatory pressure. Also good to have this solution to solve other problems

Ben: The analysis should still focus on real world IDs.

Ben: Again, negative analysis doesn’t mean we don’t see future on this

Rick: Judgment call for shipping decision. Still worried about warning without an alternative.

Joseph: Browser API does solve a security issue in the cross device flow versus other existing approaches.

Tim: Analogy to FIDO problem w.r.t. legislation, been around for 7-10 years and regulations still require password + SMS.

Tom: To fix custom schemes, you just need to make them registerable.

Tim: Not just that; it doesn’t solve the wallet selection problem. Recommend looking at Rick’s writeup on the custom schemes analysis.

Tobias: Underscore the importance of cross-device flows. Those are very vulnerable to phishing attacks. Having a secure cross-device capability is important.

Nick: An interesting idea of Hicham’s proposed mitigation to observe what’s abused and then make corrections after it’s deployed and observed, but we should define ahead of time what’s appropriate and what’s not, and what we are watching, and what changes we can make. Because some people might be fine with ubiquitous usage and not want to restrict it later.

Lee: You can only monitor if you are in the game. We need to be in a position to be able to influence the flows, which is to be in the loop.

Tim: Nick, where should we do that?

Nick: Separate documentation, or a section in the spec? It's a new approach, so we need to decide, but can pursue that documentation in either place.

Joseph: agree with Lee

Ben: make sure issues have all coverage

Should response encryption be required (#109)

Tim: Read that this should be enforced at the protocol level not web platform

Joseph: Can’t enforce this at the API level anyway

Hicham: API could enforce it. Will make it even easier for protocols

Joseph: Can enforce but cannot solve all the issues people are raising, e.g., key injection

Tobias: Hard for the browser to know whether the text is encrypted, right?

Hicham: If we have more than one protocol, it is hard to have different encryption and different encryption levels.

Tobias: My point was different. Highlight the possibility of colluding parties to pass back an unencrypted response. Highlighting the feasibility of browser enforcement. Maybe it’s not a problem

Ben: Good to have. It is hard for the browser to enforce. SHOULD instead of MUST.

Rick: Less worried about enforcement. Detecting abuse is hard to enforce, but we need to try anyway. Writing out the intention of the API makes it easier to justify and show warnings.

Martijn: it’s unlikely that different protocols will use the exact same encryption mechanisms. Will make it hard for RPs and wallets to use different protocols. API-level encryption eases extensibility.

Lee: Joseph, Why isn’t it sufficient to do it in the browser APIs?

Joseph: Can't expect the browser to check key attestation in the web API. Might end up with encryption happening twice

Rick: True that it cannot meet the EIDAS requirements.

Martijn: I don’t see the meaningful difference and why they can’t be standardized.

Tim: Will keep this topic on the agenda.

Clone this wiki locally