Skip to content

2024 10 21 Meeting Notes

Jump to bottom
Tim Cappalli edited this page Oct 21, 2024 · 1 revision

2024-10-21 (A Call)

Organizer: Tim Cappalli

Scribe: Ben

Agenda

Attendees

Please add your name and affiliation

  • Tim Cappalli (Okta)
  • Matthew Miller (Self)
  • Ted Thibodeau (he/him) (OpenLink Software)
  • Heather Flanagan (Spherical Cow Consulting)
  • Benjamin VanderSloot (Mozilla)
  • Chris Needham (BBC)
  • Wendy Seltzer (Tucows)
  • Loffie Jordaan (AAMVA)
  • Hicham Lozi (Apple)
  • Joseph Heenan (Authlete / OIDF)
  • Mohamed Amir Yosef (Google Chrome)
  • Helen Qin (Google Android)
  • Hiroyuki Sano (Sony)

Notes

Administrivia

Tim: Canceling next A call, will keep the B call as we haven't met in a while. will find a room at IIW. Thoughts on daylight time? Pin to UTC or pacific?

Mike: 9am pacific is preferable.

Tim: Anyone want earlier? Hearing none, 11/13 will be a new call series pinned to 9am pacific

Intros from any new folks?

None

Ecosystem Updates

Simone: Charter update: the formal objection’s report is under team review (next week), Council is to be formed in 2 weeks following the report publication, then the Council needs to work on it.

Tim: In summary, we should move forward around the new year.

Simone: If you have to provide timelines to formal requests from the EU, what times will you provide for a WG draft?

Tim: Early March at earliest. CG report this month. Going to have to talk about scope again.

Tim: Incubation updates: none.

Joseph: Current plan is to have an implementer's draft of the Verifiable Presentation spec by the end of the year. Hopefully with a query language finished and merged. This locks in patent protections and gives a version number. Final version would then be targeting the end of March. Similar questions from the EU.

Matt: What is the query language? High level overview?

Joseph: I’ll get back to you.

Kristina: A pruned down version of the one that exists already, due to developer feedback that it was too complicated. The initial feedback from developers is positive.

Tim: Which of the three query language proposals is this implementing?

Lee: Option 3, not including the changes of the last 24 hours. Plan was to implement a wallet to make this work, then add more complicated bits. Goal is to have a full implementation in a website and wallet by IIW.

Tim: FIDO board did approve CTAP 2.2 RD02.

Lee: Payment things moving forward quite quickly. Wallets are handling these things differently in UI, but it goes through OpenID4VP.

Kristina: Ditto from our side.

Lee: We need an end-to-end implementation soon. Single tap to confirm payment soon.

Lee: Helen is working on the issuance API from the platform. May be wired up through Chrome by IIW.

Tim: Do you want to demo the payment credential stuff at IIW?

Lee: Yes.

IIW agenda planning

Tim: IIW agenda planning is a good thing to do next.

Lee: Do you want to do demos in the demo hour or in the session?

Tim: Dedicated session would be good, to prevent mobs. Also allows Q&A

Heather: Ditto, session is better.

Lee: Interactions with OpenID4VP mean that we probably need to have adjacent sessions

Kristina: I’m okay to do that.

Tim: The payments and issuance discussions will probably be pushing a lot of conversation

Joseph: Purpose of the request is something we should discuss with browser vendors.

Tim: Adding a session for you to talk about this.

Tim: We should talk about all of the details an RP needs to know at IIW.

Joseph: This is a challenge, when thinking about error codes and allowing the RP to continue a flow.

Matt: You are going to hit the “enum” vs “open text” error type concern.

Tim: Absolutely, we need to have that conversation.

Lee: We could define it in OpenID4P. This is coherent with the `get` in the current API. We provide a blob of JSON.

Joseph: I didn’t mean to imply we need the details at this API level.

Lee: Yeah, just clarifying, but it is a nice solution since we already solved a similar problem.

Lee: I may also do a session on anonymous presentations. ZK, mDocs, etc. The problems with mDocs keep coming up. So we can talk through the issues and solutions, such as our ZK stuff. ISO seems to care less about linkable presentations.

Ben: Can we get the mDoc ZKP whitepaper?

Lee: I want it too and will bother Abhi.

Tim: Punting issuance discussion to next week.

PR & Issue Review

CGR1 Blockers

Tim: I’ll edit this into text this week.

Tim: We need more concrete examples than real world identity. Let’s add them!

Nick: The timeline for the first CG report leaves privacy and security considerations. We need to have those written before it is published as such.

Tim: Do you believe we are ready to have spec text for this?

Nick: If we think it is complete enough to be a report, then we better have security and privacy considerations written.

Tim: Do we have volunteers to work on that?

Nick: I can.

Tim: Anyone disagree that these should be blockers?

Matt: I have an additional security concern. Is there a document around the properties of issuing these? WebAuthN has something like this.

Tim: Not needed in the first draft.

Nick: Let’s add a note at least. Also using an issue to track it would be good.

Matt: Unrelated question: on #181, does that include issuance as well?

Tim: No.

Matt: Is there a “caliber” of credential worth considering? Self-issued okay?

Tim: I don’t care, I just want more use cases. University degree, federated sign in, etc. Non-normative examples so we don’t care too much.

Sam: I would avoid federated sign in. We talk about it less, and is this the right API?

Tim: If it can be used via this API, we should mention it. Not sure if this API is the best one for that use case.

Sam: I think there is a distinction between the protocol and the use case. Should these be suggestions or descriptions of constructions? We don’t deal with issues that FedCM does, so I wouldn’t want to steer users to this as an off-the-shelf solution.

Lee: There is an intersection, though! Southwest loyalty membership is an example. It can show powerful identity, but makes a lot of sense to log in to Southwest’s website with it.

Tim: Federation is a trigger word. Let’s avoid it in the doc.

Manu: There are 30+ use-cases in the VC use case doc: <https://w3c.github.io/vc-use-cases/#user-needs>.

Tim: Thank you.

Helen: Is it a blocker or part of the goals to define all of the formats for these credentials?

Tim: That is the million-dollar question that is holding up this ecosystem. Let’s not put it in here.

Manu: +1 to Tim. Out of scope for this group.

Lee: Agree. Browsers caring about this is a sign of failure.

Heather: We see requests for authentication API via this API. It would be nice to point users to an answer rather than ad hoc solutions

Tim: That is the point of WebAuthN. Tell them to use it.

Manu: +1, a credential format group would be worth working on this. The VC group here at W3C is a candidate for this work.

Sam: IIW discussion would be good for the relationship between WebAuthN and Digital Credentials and FedCM. I feel the tension between these.

Tim: Yeah, that is probably the audience to have that discussion

Lee: Yeah, I’d like to participate in these conversations. We see use cases where they hit multiple of these APIs. We, as a community, need answers.

Sam: Framing is useful.

Heather: I’ve seeded these conversations. Let me know if I can help.

Sam: I have an intuition that there is a related discussion with OIDC & ???

Ryan (in chat): mDL should be proof of identity with the passkey being bound to a proofed identity for ongoing authentication. The idea of stepping up a pseudonymous authenticator with a full identification is not ideal.

Lee: I agree with Ryan in chat. We need a way to explain this externally. And UI is much better for digital credential membership cards than passkeys.

Tim: Passkeys work everywhere on almost all devices. Wallets are fragmented.

Lee: Let’s be able to explain that.

Tim: Who is going to do the 10 years of work that got passkeys to work everywhere but for Digital Credentials?

Matt: So, ease of implementation to control spectrum could be one framing.

Tim: That solidifies the need for this discussion. We are at time! Please chime in on the issues that we have that we did not get to.

Discussion

Issuance

Issues without owners triage

https://github.com/WICG/digital-credentials/issues?q=is%3Aissue+is%3Aopen+no%3Aassignee

AOB

Clone this wiki locally