2024 09 23 (TPAC) Meeting Notes - w3c-fedid/digital-credentials GitHub Wiki

2024-09-23 (TPAC Meeting)

Chair: Tim Cappalli

Scribe: Pam Dingle and Rick Byers

Agenda

14:00 - 14:10 Welcomes & Administrivia all
14:10 - 14:15 Working Group charter update Simone, Heather, Wendy
14:15 - 14:20 Chrome + Android demo Lee & team
14:20 - 14:35 Browser Engine Roundtable Browser engines
14:35 - 15:05 Last Call for Breaking Changes for ARF/eiDAS/OpenID4VP discussion
15:05 - 15:20 Graduating from the WICG: What would it take to get to a FPWD in the FedID WG? discussion
15:20 - 15:30 Issuer identity in selective disclosure cases (issue 139) discussion
15:30 - 15:45 Support for issuance (issue 167) discussion
15:45 - 16:00 Web wallet integration (initial discussion) discussion

Attendees

  • Tim Cappalli (Okta)
  • Heather Flanagan (Spherical Cow Consulting)
  • Matthew Miller (Self)
  • Helen Qin (Google Android)
  • Lee Campbell (Google Android)
  • Wendy Seltzer (Tucows, Invited Expert)
  • Sam Goto (Google Chrome)
  • Pamela Dingle (Microsoft)
  • Rick Byers (Google Chrome)
  • Kyle Den Hartog (Brave)
  • Joseph Heenan (Authlete / OIDF)
  • Alan Buxey (MyUNiDAYS Ltd.)
  • Zachary Tan (Google Chrome)
  • Ashima Arora (Google Chrome)
  • Mohamed Amir Yosef (Google Chrome)
  • Martin Alvarez (Huawei)
  • Bumblefudge (Protocol Labs)
  • Benjamin VanderSloot (Mozilla)
  • Martin Thomson (Mozilla/TAG)
  • Nicolas Pena Moreno (Google Chrome)
  • Simone Onofri (W3C)
  • Wonsuk Lee(ETRI)
  • George Fletcher (Capital One)
  • Aaron Selya (Google Chrome)
  • Susan Stroud (self)
  • Yi Gu (Google Chrome)
  • Theresa O’Connor (Apple/TAG)
  • Daniel Appelquist (TAG)
  • Kristina Yasuda (SPRIND)
  • Nina Satragno (Google Chrome)
  • Brian Campbell (Ping Identity)
  • David Waite (Ping Identity)
  • Hadley Beeman (TAG)

Notes

Welcomes & Administrivia

Working Group charter update

  • Heather: There is a formal objection against the recharter of Federated Identity WG
    • Working with the person/org, looking for compromise. A council is being formed and a note went out to the advisory council
    • In the meantime — the issues will be discussed in the Federated Identity WG meeting Tuesday afternoon, all welcome
    • Simone is here if anyone wants process questions answered (point from Tim)
    • Links to the formal objection will be added to these notes
    • Quick summary is that the objection centers on certain identity operations being made easier. The question is, is that a good thing or a bad thing?
  • Lee: What is the timeline?
  • Heather: Council not formed until early October, but preparations and conversations are already in process. I am hoping this is a 2–3 month resolution rather than a year
  • Tim: In the repo, there is a document called “custom schemes”. We are fixing some of the market interactions as we go.
  • Mark: How much of the council deliberations will be public?
  • Tess: The council releases a report; the deliberations will not be released.
  • Wendy: The team report that goes to the Council is also public.
  • Tim: This item will be an evergreen item until it is resolved.
  • Tim: Questions on charter, procedurals? (no)

Chrome + Android demo

Lee/Helen demo

  • Multiple players in API. This is using Chrome’s origin API, calls into Android, which then calls to the wallet, driving consent.

  • First demo — same machine

  • Phone with wallet app and fake drivers license

  • A request to verify results in a choice screen

  • One credential matches, user selects continue

  • Wallet App UI shown with final consent

  • Verifying website shows what was presented.

  • When it comes to cross-domain, we can use the CTAP protocol (from passkeys) to create a “tunnel”

  • The same demo occurs as before

  • QR code on another platform links to the phone

  • Same flow proceeds

  • Questions:

    • Tony: When you say issuer with a wallet, is it true the mDL comes from an issuer? If so, taking that information from the mDL and doing selective disclosure is happening, correct? If so, wouldn’t it contain the original signature?
    • Lee: This is a complex answer. What comes back depends on what you request. You will see statements signed by the issuer.
    • Tony: So you will return the same response as 18013-5?
    • Lee: Yes.
    • John B: Different wallets may do different things.
    • Tony: But it is up to the wallet what comes back.
    • Lee: It could even be encrypted stuff coming back.
    • Tony: So would the API cover all the different formats (mdoc, VC)?
    • Tim: This is just plumbing; whatever comes back, comes back. Right now, the API only supports presentations from XX (somebody help here if you can) and OpenID4VP. More could follow.
    • Martin: Concerned about the privacy angle with selected disclosure. We saw on the screen that you were sharing some information, but in practice that isn’t what you are sharing, because this is a salted hash SD-JWT that has very specific privacy challenges.
    • Lee: Things like MDOC convey more than what the API covers; you will also reveal other salted hashes that are tracked across sites. We need to manage these correctly.
      • This is an important discussion on how what is disclosed is communicated to the end user. This is the question of whether we should encourage selective disclosure.
    • Martin: The implications of this "buying alcohol" use case is not obvious.
    • Lee: An identifying presentation is definitely less obvious. If there are presentations that are anonymizing, then it is problematic if the implementation reveals extra hashes and other information.
    • Tony: Looking at the API, I didn’t see … people want to know how the identity piece happens, not just how the authentication piece happened.
    • Tim: This API is deliberately transparent. This selector may not have shown it
    • Lee: The API itself takes 2 parameters: the protocol and (something else). Our API tries to figure out the credential intersection. On Android, we need to query each wallet to see if a credential matches. Say there are 3 wallets; we don't want the other wallets to know what the other apps have. Any app can be a wallet. We take the query, fire it to the wallet, and allow the app to run code to decide if they are affected; this happens in a sandbox. Once you decide you are affected, you (the app) will authenticate the user, show consent, etc.
    • Tim: If you are familiar with deep links, this API just takes over that process. In the diagram, we are talking about the green line. (need link to diagram).
    • Tony: How does this apply to custom URL strings?
    • Tim: That's what this API is replacing.
    • Next section: Browser Vendor update
    • SamG: We have an origin trial running; they run 3-6 months. It happens in Chrome Stable, so real users are using it — a great way to get feedback. From there, we assess user satisfaction and applicability to the ecosystem. It is a structure where we can change the API as we learn. origin trial is running from browser version 128 to 134. This may also be available in Edge
      • Cross-device flow is also getting ready to be behind a flag in Chrome (it is almost ready) — will merge into the origin trial
    • Rick: We announced that Google Accounts are starting to use this soon, in cases where somebody changes a birth date (e.g., becoming a major after being a minor)
    • Tim: There is a change to a CTAP2.2 protocol that has gone through workgroup approval but needs board approval. Hopeful-ETA is EOY.
    • Martin: The dystopia is here, it’s just unevenly distributed. Wrt selective disclosure, we (Mozilla) can’t make it work so far. More than just the things you choose to disclose are being revealed. We think it would be irresponsible to ship that without understanding it.
    • SamG: In this model, part of the responsibility is shared with the wallet.
    • Martin: If you’re OK with that, then great, but we don’t think that will work; we need people to properly understand what we are shipping vs. what we are delivering. The age example demoed worries me quite a bit. I don’t think folks would want to be surprised by the data going back to the issuer. It seems to be an inherent property of this API to handwave over whose responsibility this is.
    • Rick: Age verification is already widespread and already relying on a contractual relationship that says privacy will be maintained. We don’t think this is any worse than that.
    • Martin: We don’t need to aid and abet that process.
    • Rick: Today, Mozilla will allow you to take a pic of your license.
    • Martin: Yes, but today the consequence of that action are obvious.
    • Lee: But if you want to just share “age over 18”
    • Martin: But you aren’t only sharing that.
    • Kyle: This is the same issue we see — how do you break down agency? We are deferring to another entity, and how do you know if that entity is behaving? Is consent done? This appears to us as a risk. The way in which we approach it by overscaling, it doesn’t allow us to represent the model.
    • MattM: I can hear the concerns on implementing this functionality. There are organizational liabilities, but the idea that we can have the same sort of identifiable information over a custom scheme rather than over an API, but if we go through the W3C process there is value in having greater visibility/oversight — I don’t think that should be discounted.
    • Ben (Mozilla): Issuer/verifier linkability is as much of a concern re: the browser’s user agency as issuer identity, and is harder to explain to the user.
    • JohnB: I agree, and EU folks also agree that issuer/verifier collusion is a concern — the EU has a timeline for delivering this functionality; they need to mandate the use of custom URIs or something else, but they will mandate something. Question is, can we use this pipe to influence some of the other decisions — there are some people who will do some fairly bad things; it would be good if we can use this to encourage other parts of the ecosystem to come up with better zero knowledge options. The short term options may not be great, but they allow for oversight
    • Tim - Simone is leading a threat model discussion, later today is the Federated Identity WG where this will be updated.

Last Call for Breaking Changes for ARF/eiDAS/OpenID4VP

  • Tim: There is a lot going on with the ARF and the EU. Did a last call for major breaking credentials, big ones were navigator.credentials move, and changing provider to request and request to data (somebody confirm); those very core changes are done. The API is currently simple, most of the complexity is in OpenID4VP — is there anything else that needs to be changed that is big? What can we do to create to make the first CG report — using the tag cgr1-blocker
    • First question, what protocols are supported? — now we have 1 but want to be ready for #
    • JSON serialization methods — want to get the serialized request/response from the server.
    • Want to add a statement that all responses to verifier must be encrypted.
  • Tony: Is encryption expected to be point-to-point or something else? There could be backend components that prevent encryption. Is this message level?
  • (lots of people chiming in)
  • Tim: What passes back through the API is expected to be encrypted. Getting into the registry may also need some unencrypted information.
  • Martin: Malicious router extensions…
  • Lee: We accept that we need to protect the request from other parties, but the request is more point-to-point, so it is less available.
  • Martin: If your solution requires that you protect the information — most of those requirements can be met by an application that receives unprotected information and does what it needs to do. Having a wallet do the encryption causes the browser to be blind.
  • Lee: I don’t know about Sam but helping the app to maintain its requirements…
  • Sam: Can we remove as many issues as we can to get to the CG report as quickly as possible? There are time considerations it is important to be sensitive to.
  • Tim: We tentatively set a deadline of Oct 31.
  • Kristina: This document that legally mandates technical mechanisms is being written. If you believe this technology should be used to protect 300M Europeans, then you need to report out in time for that process. We are grateful for the WICG cooperation so far. It would be great to have a stable version by the end of year. We need a stable reference — Oct 31 needs to be checked but sounds like a (reasonable? good? fair?) deadline.
  • Sam: That’s just over a month.
  • Tim: There are 3 open issues on screen; does anyone think any of the 3 can/should not go forward? (if someone with github open could link to those open issues that would be great)
  • Sam: Wrt encryption, there is no browser code that gets written.
  • Kristina: We could mandate this in OpenID4VP, too.
  • Sam: Maybe that’s easier to do.
  • Tony: There is the same issue in mDL, where VP was doing the encryption, but it still had to be stated in the spec that this is end-to-end encryption.
  • Sam: A non-normative statement is reasonable to me, but I want to be clear that this isn’t something that the browser can enforce.
  • JohnB: I’m not sure everyone wants end-to-end encryption.
  • Tony: That’s why it would be non-normative.
  • Tim: If we are saying it is required to be in the registry, I know some of the registry work is in the air.
  • JohnB: If there are 2 versions where one is E2E, and there is an alternative, that would be fine.
  • SamG: At the minimum, it would have to be a SHOULD not a MUST. Isn’t it possible in OpenID4VP that it doesn't use encryption?
  • JohnB: Yes, there is alg:none.
  • BrianC: There is something in OpenID that allows a non-encrypted response.
  • Heather: The questions of normative, etc., aren’t relevant while we are doing a CG report anyway.
    • Comment from Zoom chat: bumblefudge to Everyone (Sep 23, 2024, 3:07 PM):
      To come back to Tessa’s point about a CG Report misrepresenting its opinions as normative statements, it might be safer for those “two sentences” to describe the prototype that inspired the report rather than all future conforming implementations, i.e. “one way of handling the message level security that we prototyped with OIDC4VP…but how future registries works is TBD by WG process
  • SamG: Can we just omit?
  • Kyle: May be missing context. What are we trying to address with encryption if we can guarantee we are passing the data on?
  • JohnB: There could be a man in the middle. The wallet may have the ability to validate the encryption key so that only the truster verifier can encrypt.
  • Martin: Is the key negotiation expected to be magic?
  • JohnB: It is encoded in OpenID4VP; original proposal had the key in the top level of the API.
  • Kyle: So this is the case where there are intermediary OPs acting as verifiers in OpenID4VP?
  • JohnB: Yes, either intentionally or unintentionally.
  • Kyle: So this is where you are breaking the original model, and you are compensating for that — this answers my question.
  • JohnB: If this was just a matter of encrypting to a random key, that wouldn’t make sense, I agree.