Skip to content

2024 03 25 Meeting Notes

Jump to bottom
Tim Cappalli edited this page Mar 26, 2024 · 1 revision

2024-03-25 (A Call)

Organizer: Tim Cappalli

Scribe: Rick Byers

Agenda

  • Administrivia
  • Intros from new folks
  • Updates from incubation
    • Anyone from Google or Apple have any updates?
    • Anyone prototyping with their wallet or verifier?
  • Any general updates from the OpenID DCP Working Group?
  • Feedback and asks from NIST (Ryan Galluzzo)
  • Feedback and asks from the European Commission (Paolo De Rosa)
  • Feedback and asks from the California DMV (Ajay Gupta, NOT CONFIRMED YET)
  • AOB

Attendees

  • Tim Cappalli (Okta)
  • Rick Byers, Google Chrome
  • Dirk Balfanz, Google
  • Oliver Terbu, MATTR
  • Loffie Jordaan (AAMVA)
  • Hicham Lozi (Apple)
  • Orie Steele (Transmute)
  • Lee Campbell (Google/Android)
  • Tim Shamilov (Block)
  • Nick Doty (CDT)
  • David Waite (Ping Identity)
  • Joseph Heenan (Authlete)
  • Sebastien Bahloul (IDEMIA)
  • Andrew Regenscheid (NIST)
  • Ryan Galluzzo (NIST)
  • Benjamin VanderSloot (Mozilla)
  • Jin Wen
  • Derek Hanson (Yubico)
  • John Bradley (Yubico)

Notes

Administrivia

Tim: Meeting chat usage. Will just leave it open. If you don't want notes recorded in minutes, use the meeting chat. If you do, then use slack.

OpenID updates

Gail: Don't have Kristina or Torsten due to conflict with german

Joseph: have a working document in the DCP working group, on how OID4VP would be used over Browser API. Discussing at the WG meeting tomorrow; Torsten hopes to show it here in 2 weeks time.

Feedback from Ryan from NIST

Ryan:

  • Some of you have heard from me, post at last meeting
  • This work is really important, important to NIST
  • Lots of key issues in mobile drivers licenses and VCs, tackled before hitting scale in the US. Invocation and selection, custom URI schemes. Secure cross device flow, particularly important for the US government. Notall - of our stakeholders are using mobile apps.
  • Critical work you are all doing amazing effort so far
  • Like to see the work transition out of incubation and ideally into a WG, ideally in the most efficient manner possible. Don't want to rush, don't know all the W3C processes. Want to open the door to how to transition. -Are there key tasks, issues, concepts that need to be handled? What is the most appropriate pathway?
  • I know there's been discussion of transitioning to FedCM or its own WG. We don't have a formal opinion on that. Just want a known pathway and critical path items (scope, responsibility, etc.) where to go next.
  • Two primary reasons we're interested:
  • See it as credibility important to securing and scaling mDL and VC. Want to experiment with browser and platform APIs in NCCOE. But we feel we need to see it transition to a draft standard with contributions anddecision - making processes that gives us confidence that it's representative of a broader set of contributors.
  • Once we've got that buy-in and support from a broad community in W3C, then we're in a better position in NIST to pick this up
  • Want to see a path forward with OIDF. Overlaps between two standards, sync'd up so we have a consistent view and can roll to implementation as efficiently as possible.

Lee: Can you give us background on what NIST is ultimately trying to produce and where guidance would go? We've seen each state do their own thing, AAMVA guidelines. Is NIST's role federal guidelines for all this stuff?

Ryan: We don't have authority over states and DMVs, but we do provide guidance to federal agencies who may consume MDLs. We might be asked to provide something more implementation focused. We want to provide information to RPs on how to understand mDLs and consume them from tech. Might be asked to do something on issuance too, but right now how it is consumed, how to mitigate risks in authentication use cases. Our purview is 63b and 63a (online remote identity proofing). Presentment falls into bucket of 63c

Lee: Would it cover documents like green cards? Guidance to those orgs?

Ryan: Yes, how it's presented and how it fits into assurance level use cases. We don't provide requirements to the issuance side since those are under other entities (state dept covering passports). How do we provide good technical guidance to present and consume?

Gail: Can you elaborate on what good might look like from a roadmap perspective for the weeks and months ahead? Any preferences or viewpoints?

Ryan: Worst case scenario is identification dependencies and high-level timeline. In practice, it sounds like it's already started within DCP profile work that fits within the browser API support. Understanding where there might be decisions in the W3C environment to inform the OID front and vice-versa. Making sure they're addressed. We obviously don't have the same timeline constraints that eIDAS has, so more time sensitivity there. But we're also very interested in how the two standards fit together and how they can be coordinated to ensure we're as efficient as possible with everyone's contributions.

John Bradley: Is the scope you're looking at greater than mobile driver's licenses? Like, how would the federal government consume European IDs and passports?

Ryan: Answer is yes. Open to discussion of understanding the impact of expanding beyond mDL/mdoc and making sure VC is part of the conversation. But, we would like to see something supportive of many credential types.

Andy: challenges in terms of adoption, but important for interoperability to facilitate cross-border use of digital credentials

Tim: Most delicate balance we have is that IMHO everyone we need is here. The minute we move this work, legal processes have to start again. People on the call may need over a year to do that work. We need to do that in parallel. Better identity WG charter is approved without this work in it, but now we will go through another process to add this work item to that charter. We do need companies to be transparent as to when they can join the WG. We can keep making process here, but we need to navigate the flip carefully

Gail: Is there a timing for NIST for NCCOE (separate from EUDI)? What is your best case scenario? Tim, what is "better identity WG" — same as "federated identity WG"?

Ryan: No hard and fast timeline. Going to work when available. Working on 18013-7 and OpenID4VP as currently defined. By 2nd use case, we'd really like to have a draft standard to point to for our 2nd or 3rd (or ideally even 1st) build. Summer? Don't want to lay out an unrealistic timeline. Probably more important than that timeline — what are the remaining critical path issues that need to be addressed by the incubation group so that we're comfortable transitioning, and how can we help contribute to those gaps? Don't want to force a pathway; just want to understand and see a clear path.

Tim: Sorry my bad, no name change.

Kristina: Want to add color to the statement "all the people we need are here" — true from the browser side, but from OpenID4VP, it's not true. A few DCP WG members don't necessarily transfer all the knowledge here. We should be clearer on the responsibilities between the two standards organizations. While it's a CG in W3C, for OID we have a WG that is chartered to produce specifications. I hope we can deep dive there and be clear which standards org is responsible for each org.

Ryan: We talked briefly with Gail before you joined on the importance of a combined timeline between OIDF and W3C. One question, are there any additional standards bodies that need to be engaged on this? E.g., not sure how we want to deal with CTAP for cross-device workflows — does that fit within W3C, or do we have to ask permission from FIDO or IETF? I don't know. Potential dependencies

Tim: Sorry my comment about right people was just comparing CG to WG. CGs are more accessible because you don't need to be a paying member.

Sam: In the absence of the browser API, can you walk us through your current architectural choices? Assuming you're using OpenID4VP as a protocol. What are your choices about formats (VCs, mdocs)? And what about query languages? Protocol, format, and query languages in your stack right now?

Ryan: we don't have anything in our stack right now — still working on our build phase. Some will depend on what our participants will be able to support. Initial use cases will have to be mdoc since that's the majority of implementations. We'd like to see VC just due to clear support in Europe and states like California. And we're looking at OpenID4VP as probably being the first presentation stack we'd look at. Not very interested in 18013-7 REST API. Query language would be constrained by what OpenID4VP supports. Ultimately, does that impact the API or decision to leave out? If it's a key gap issue, happy to engage in that conversation.

Tim: One comment on cross-device. At this point, it's a minor change to CTAP (just essentially add a message type field). The hope is we'll just get that into CTAP 2.2 before it goes final. Want to get it final by summerish, but 90 day period. Because we never released CTAP 2.2 outside draft, it would just be the normal implementation used by passkeys. Current thinking, open to feedback.

Ryan: Don't have a strong opinion other than it needs to get done and we need to be able to appropriately reference it.

Tim: Yes would be allowed in the same way WebAuthn references today. Public specification.

Lee: Curious about use cases you envision, especially sign-in as primary authn mechanism. Signing into banks was one of your key use cases I think? Where do you see this fit alongside passkeys? You'll hear people say this shouldn't be used for authentication, only for presenting identity. But some use cases look like authentication.

Ryan: Since current methods for mdoc and VC aren't phishing resistant, I wouldn't want to point to them as primary authentication methods. Will probably look at binding to a FIDO2 WebAuthn credential — whether that's a passkey or not. Our inclination is to focus on mdoc as an aspect of identity proofing and leave authentication to the side. I don't know how that will evolve in the future. There are discussions of using VCs for authn in europe. We want to test that out, but our current stance is that we prefer to focus on WebAuthn for authentication and VC/mdoc for identity. But would like to get to the point that both have the same phishing resistance properties

Lee: For phishing resistance, is that just how OpenID4VP stands, or something fundamental? Do get the origin in responses with the browser API. Not quite exactly the same as what we do with passkeys. But it only comes with browser APIs, not with other presentation schemes.

Ryan: The other main issue we run into is the cross-device flow. Federal agencies will have to deal with users who are presenting mdoc/VC from their laptop to their phone and vice-versa. We need something to mitigate the replay attack.

Lee: Definitely high on our list, should get all the same protections as passkeys. If you come to IIW, we might even show you.

Ryan: I'd like to come to IIW but have a conflict, will try to get Bill there.

Tim: I've been assuming that most of these RWI use cases will be cross-device. Use cases are like filing taxes; most people aren't doing that on their phone. On the phishing front, the phishability is different here — someone can phish for claims, doesn't exist on passkeys. Inverse phishing problem. Passkey is a utility to an RP and they can look for it. Now we flip it and you can phish the user for a bunch of claims. I don't believe mdoc/VC will ever be 100% phishing resistant and that's OK. The goal is to reduce the risk as much as possible. Hybrid plus signing over the origin is good enough.

Andrew: Can you reiterate what the explicit steps you see for getting this into a WG?

Tim: My understanding is WG approval went through because it was already voted through by the AC. Then as soon as next week they will start the process of adding this work item and it'll go through the same process, but will likely have some opposition. Then it's up to this group as to when it moves. Right now I suggest people start doing legal reviews to join the new WG since it'll exist next week.

Andy: Is there a consensus that that's the right place to move it? Seems reasonable, but is it the decision?

Tim:I wouldn't say there is 100% consensus but it's fairly close. I have concerns about it being lumped in with very large work items. There are three styles of WGs in W3C (unofficial) — one deliverable like WebAuthn, WebAppSec; at the other end where everyone brings things; then some in the middle. I just fear one thing getting more attention than another. Since FedCM is much further along, there might be a strong incentive to pay more attention to that. Not a big deal, but a concern. Creating a second group is a headache for companies who are going to join anyway.

Sam: I don't feel strongly on which WG this goes to, any will do. There are two types of objections: to which WG this goes, or moving to a WG at all. Anyone in this call have concerns we could talk to here about possible objections?

John: I don't necessarily have a huge concern myself, but Tim has raised the ire of the open source community and now has a big target on his back because of some open source project and people's ability to participate without paying. So we can expect some number of people to object to having to pay $25k/year in order to participate in the WG so there will be people who feel excluded unless there's a way to bring in invited experts (which W3C doesn't love doing because it cuts into their revenue). Big question is inclusiveness.

Tim: Want to explain more — passkey authenticator open source groups, very low security bar not necessarily conforming to the spec. Asked them to engage but turned into an argument about FIDO being anti open-source.

Nick: Certainly agree that access points are important. W3C has the capability to get work done in public view and include more people as invited experts. I'm happy to help push W3C on this. In the federated working group review, I did preemptively note on behalf of CDAT; if digital credential API was going to be in scope, we'd want to see some protections in place for human rights before the organization commits to it. Should be a pre-req to having a consortium wide commitment. I think there's work to be done. We want to be confident it can be done in a non-harmful way before we commit.

Gail: Good to hear from Ryan and Andy that there weren't necessarily reservations on migration from CG to WG and we pointed out open source community concerns that will probably continue. Are there other governments who will have concerns? Maybe timing is everything, and we'll be able to have human rights issues addressed as Nick says, and other entities overly influencing outcomes of working groups and barriers of entry for governments and other stakeholders.

Ryan: We don't want to force it down a path just to force it down a path. Want to do it right. Don't want to do harm either. Just want to get something to a standard that everyone is comfortable with sooner rather than later.

Dirk: If Paolo had been here, he'd probably give us an even shorter time table than Ryan did. If the goal is to get this into the FedID WG as an additional item, does anyone see substantial hurdles to that as an idea? Or are we all in agreement that that's plan A? If we don't get this into a shape that Ryan and Paolo are happy with, then we're going to end up with mechanisms used for digital identity that aren't as secure for users. I'm worried we're making perfect the enemy of the good.

Lee: This stuff is coming to your web browser whether you like it or not. It's either coming via OpenID4VP as it exists today, or it'll come via the browser API. I think we'd rather do it via browser API because it has better security and privacy properties. If we have reservations around maturity and correct protections, if we're waiting for that, then it's going to end up in your browser anyway. My view is, let's address some of these blockers and get it into a draft space so the regulators have something to point at.

Tim: One misunderstanding — anyone can look at issues and comment on them even if not a W3C member. You just have to be a member to create PRs. Given the constraints, that's pretty awesome. We have people submit issues to WebAuthn all the time; we address them and move on without them ever being W3C members.

Tom: Lee says it'll go through the browser, but my understanding is a large majority won't go through the browser at all. Most will be point-to-point. I don't want to talk to a website; I want to get beer at a convenience store.

Lee: That's big, but not in scope for this group

Tom: Then this group isn't the place to address the problem.

Tim: Problem statement for this group is presenting such credentials on the web.

Sam: By default, if we do nothing and we don't get this to a WG so Ryan and Andrew can't depend on this, they're going to use OpenID4VP over custom schemes. Nick, which world is better to be in? If we don't act quickly, it puts us in a position where we're disintermediated and we have no ability to act on these concerns. Can you help me understand how your goals would be better or worse served on these two alternatives?

Nick: I can see that there might be other worse alternatives. I'm trying to work on privacy and human rights work ASAP because people will be exposed to those pressures. I don't think anything that's less bad than the worst thing needs to get full-hearted support. I understand that there can be worse mechanisms.

Joseph: My employer is not a W3C member. What you said about people being able to participate other than opening PRs is different from my understanding.

Tim: We can get someone from W3C to confirm. But in WebAuthn 50% of the issues are from non WG members.

Joseph: What about meetings?

Tim: Don't know.

Gail: What are the mechanisms to ensure that no single entity or couple of entities can overly control this spec, and that leads to some future backlash of those entities over controlling the spec. That's one of the most important issues to resolve. It's the kind of concern I hear come up over and over again in back channels. Not sure if an

Tim: I think the DID spec is one of the best examples of that. Lack of consensus, W3C formal objection. Process was followed and action was taken. Quite rigorous in W3C. In theory, that can be addressed there.

Martijn: going through setting up a WG is precisely the point we get that feedback. There's a set of things here which are very hard to do without browser / OS support. So best for everyone involved. Not just a minor thing, but a broad capability.

Torsten: As experts in W3C, what's your assumption on when we'll have a final spec? Something published as W3C REC.

Tim: Can go as fast as WG wants. But I'd realistically say, by the end of 2025 for the entire process. We're barely through incubation. That's my gut feeling based on how WebAuthn has gone. There are other document stages like public review drafts which can be formally referenced.

Torsten 1.5 years is actually pretty fast.

Clone this wiki locally