-
Notifications
You must be signed in to change notification settings - Fork 9
2024 09 09 Meeting Notes
Organizer: Tim Cappalli
Scribe: Nick, Heather
- Administrivia
- Intros from any new folks?
- Any updates from incubation?
- Any updates from the OpenID DCP working group?
- TPAC Info
- Discussion
- Issues without owners triage: https://github.com/WICG/digital-credentials/issues?q=is%3Aissue+is%3Aopen+no%3Aassignee
- AOB
- Tim Cappalli (Okta)
- Heather Flanagan (Spherical Cow Consulting)
- Joseph Heenan (Authlete/OIDF)
- Wendy Seltzer (Tucows)
- Nick Doty (CDT)
- Lee Campbell (Google Android)
- Brian Campbell (Presumed long distant relative to Lee but no affiliation with Google)
- Mike Jones (independent)
- Benjamin VanderSloot (Mozilla)
- Ted Thibodeau (he/him) (OpenLink Software)
- Ryan Galluzzo (NIST)
- Manu Sporny (Digital Bazaar)
- Hicham Lozi (Apple)
- Hiroyuki Sano (Sony)
- Mohamed Amir Yosef (Google Chrome)
- Sam Goto (Google Chrome)
- Dirk Balfanz (Google)
- Loffie Jordaan (AAMVA)
- Andrew Regenscheid (NIST)
- Sebastien Bahloul (IDEMIA)
Tim: As we start to think about moving to a WG, we need to close or tag issues to decide when they will be addressed. Today, assign an owner to each issue.
No new folks.
Joseph Heenan: OpenID4VP Conformance Test Suite now supports testing with the browser API. Basically works! Opened some issues/notes on Chrome.
Joseph: EU Implementing Acts don’t mention the OpenID specs, only 18013-5 and W3C VC, because laws can only refer to final specifications (apparently). Advised that to get into the next version, should have a final spec by the end of the year. Discussed on calls last week but also sent details to the OpenID4VP mailing list. Avoid confusion for implementers by getting them into the next version of the law. Definitely won’t be finished, but have something that can be referred to. Could have a 1.1 version soon after that would be cited in a future version of the law. Some things must be done in the next couple of weeks.
Lee: If 1.1 has the new query language, that would also end up in the regulation; that would be good. Expect to have an opening again next year to update spec references in EU regulations.
Hicham: Query language is not in 1.0 — isn’t that a breaking change?
Joseph: Make it clear in the 1.0 spec that there could be alternative query languages. but not feasible to get the new query language in on the current timeline. Presentation Exchange and new query language both to be included in the spec. Version 2.0 could make breaking changes/remove features.
Sam: Deadline for normative changes and PRs?
Joseph: End of year deadline, but OpenID Foundation process has 2.5 months between finishing changes and votes/final publication. PRs open within 2 weeks at the most. Focus on anything that would be a breaking change or an extensibility point.
Hicham: Any chance to get the query language into 1.0?
Joseph: WG final decision hasn’t been made, but, practically, would need compliant interoperable implementations, and I don’t see that happening within the next two weeks. Instead, work on it as quickly as we can for 1.1 revision.
Lee: I could add it to OWF Wallet and test site, but not aware of other implementers.
Joseph: Even if in 1.0, it would be in such a rough state, taking more time is probably the right call.
Brian: +1. Don’t hold query language up to a higher standard than Presentation Exchange, which may not be interoperable in a meaningful fashion.
Mike Jones: During the 45-day review for Implementers Drafts, Working Groups have added features and this doesn’t necessarily require restarting the review period unless an OIDF member asks for it to restart. We could similarly do that during the 60-day review for Final status. I don’t like that, but would really like to have the query language in, if possible. We shouldn’t rule out the possibility. It depends on whether we have multiple implementers who have tried it out.
Mike: Here is the example of making changes to an OpenID specification during the public review period. See the note at the end starting "On April 3, 2023 ... draft 17 was published." https://openid.net/public-review-period-for-proposed-second-implementers-draft-of-openid-for-verifiable-presentations-specification/
This is what would give us the space to include the new query language in 1.0 if we have multiple implementations on board.
Tim: Main meeting Monday afternoon. Multiple breakouts — not working group meetings, but a way to involve people who aren’t already deeply involved.
… Continuation of real-world identity conversation from last w3c breakout day.
… Harmonizing identity-related APIs
… Threat modeling (Simone)
… Take a look at the agenda. Don’t have to pre-register for the breakouts. Info will be on the TPAC website.
Heather: can still propose new breakouts until September 15.
Nick: I wanted to get some discussion on how we expect verifiers to present information about purpose, why they’re asking, and what they’ll do with the info. How are we going to get that info to the user? Via website, wallet? Will there be a purpose string (as per OpenID4VP spec)? Issue 44 has this as a need, and a suggestion is in issue 134. This has some urgency because we have deployments shipping but doesn’t look like we have agreement on how this info will be presented to the user.
Manu: We have implemented the VPR specs, and there is a purpose field for the verifier, so the wallet can expose that info to the user if they want to. That goes with other verifiable credentials that can be sent by the verifier to prove who they are, and the wallet can figure out how to render all that. We’ve found it’s not good enough to just put it on the website; you want the purpose string to also go across in the initial query. We are a strong +1 to verify that query languages and protocols must embed a purpose that the wallet can show to the individual. Also want some language (possibly more UX stuff) in privacy/security sections that the wallet should inform the individual of attributes being sent over.
Joseph: For the OpenID4VP, yes, Presentation Exchange (PE) has that string in it. We thought to have something in the query language as well, but had strong pushback from implementers. Strong pushback to verifiers providing freeform text that wallets would be required to display.
Brian: Really important to consider who is displaying info to the end user and what kind of implicit trust that displays. Freeform text from the verifier that may be displayed, without context, by the wallet, gives the verifier an opportunity to present their information (subject to user skepticism) through the context of the wallet and thereby make it seem more trustworthy and legit than it actually is.
Nick (chat): Presentation Exchange editors also told me that they wanted to move to something out of band (when I suggested that they make it mandatory, which it currently isn't)
Lee: Same point as Brian. If you’re the user, how are they supposed to recognize who is making the authoritative statement? Freeform strings that are rendered by trusted UI look more authoritative than they are. If we have an API that embeds it in the web content, I would like the native apps to behave the same way. If we do this so part of it only works on the web, then we need to figure out how to make this work in the native app. Would rather information flow through to the wallet. We may also need an agreement between the wallet and the issuer.
Nick: Hearing contradictory things. Yes, there has been a discussion for 10–15 years that browsers can’t show the UI, because websites will lie. The practice has been that websites don’t provide information, and users don’t have the context to make informed decisions. Let’s do better. On the other hand, if we put it in the web content, which would make the UI question easier, then we’d need similar concepts for apps. That would be more work. Either we put it into a purpose string and confront that problem, or we deal with web content (and we would need to rapidly do that).
Hicham: It’s not an easy one. The compromise we could live with is that most of the context should come from the website and not from the wallet UI. We could have something like purpose hints that go to the wallet, an enumeration of the purposes a verifier could pick from. There are still risks that the verifier will pick the best one to get the user to accept. User consent also becomes harder to define. If you give a way for the verifier to give free text to the user, you add confusion as to what the user is consenting to. We need to be careful to not have a lot of purpose in the wallet side where the user actually consents. We can have some hints, which should mostly come from what the website is displaying to the user.
Manu: We should be careful about this. The context in which you use the freeform text is important. If we’re talking about phishing, the user has already been phished if they are on the website and have been tricked into invoking the wallet. It would be nice if they had another opportunity to back out of the phishing attempt. We look at the purpose field not from a phishing perspective but from a privacy regulation perspective. Verifiers must be clear as to why they are collecting info, and they may be required to sign the request such that the info can be used in a lawsuit later. The wallet doesn’t have to show the purpose. If the wallet has reason to believe that the requesting verifier is not to be trusted, it can determine it should not show the purpose field. You can put in text “the reason the verifier is giving for asking for this info”. We probably don’t want a UI like that unless we’re in a corner case.
Ben: The idea of something less freeform than allowing the site to put whatever they want in, the enum idea I suggested might be a way around this. What string needs to be used for this API (pepsi workflow ???)? Are we talking enum or arbitrary styling?
Tim: Good discussion, but no solid next steps. Even the comment around privacy considerations, we’re going to have to decide how much privacy behavior of wallets needs to be here, since wallets won’t be implementing this API.
Nick: Also struggling with what we’re going to do. We need to do something, though. No one wants to be responsible for this, but we do want it both at the website and the wallet. So maybe we need to do proposals for either enumerations or some description of how you’ll get this string around a PEPC element?
Manu: Not sure how much purview we have over query languages, but we can mandate that the query languages need to provide for this feature. Query languages that don’t have this feature won’t be integrated into this API.
Tim: The fact we have the registry with its requirements suggests that’s a reasonable requirement.
Lee: In the EU, each issuer defines the policies for how verifiers can get information. The verifier has to pre-register what they’re going to do and why they’re going to do it. Not every issuer is going to do this, but at least some parts of the ecosystem are trying to solve this problem. When there is a system of pre-approved enums at the issuer level, then freeform text can build on that? In the medium term, maybe the problem is solved at the issuer level, though that depends on how it’s solved, too.
Joseph: Responding to the point of mandating this within the query language: that’s putting an unsolvable problem on the people who are working on the query language. That’s not going to help us make progress.
Manu: We (VC WG) have also been looking at a “request purpose credential” which could have enumerated values and could be set by a separate standards’ setting process. Then you need to allow a credential to go from the verifier to the holder; how that credential is rendered is up to the wallet. That supports both enum stuff and freeform text. That would allow the EU to define the purposes, and all we care about is what’s sent to the verifiers. The wallet then determines how to render things.
Tim: Given that we’re two weeks from TPAC, it sounds like this should be part of the larger session. We could dedicate 15 minutes to this topic.
Lee: Let’s do it.
Nick: Do we need proposals?
Tim: If you could do 1–2 slides for level-setting, that would help. If it needs more than 15 minutes, maybe it should be a dedicated breakout session.
Lee: It takes 15 minutes just to level-set; we need a breakout.
Nick will draft a breakout session request.
Triage of issues without owners: https://github.com/WICG/digital-credentials/issues?q=is%3Aissue+is%3Aopen+no%3Aassignee
Tim: As we talk about moving to a WG, we need to make sure every issue has an owner to help drive the conversations to a resolution.
… #12 - Tagging for Manu
… #14 - Tagging for Sam (can probably be closed)
… #23 - Tagging for Sam (closing as duplicate of #25)
… #25 - Tagging for Tim
… #38 - Tagging for Manu (maybe a good breakout session; someone other than Manu would need to own that)
… #44 - Tagging for Nick (breakout)
… #52 - Tagging for Tim (to see if there is anything left actionable)
… #56 - Tagging for Tim (pending closure)
… #58 - Tagging for Marcos (there is a PR for this already
Lee: But should we have a registry at all? maybe need a separate issue for that.
Tim: One of the reasons Webauthn has a registry is to avoid spec changes, yes?
Mike: The registry is there to help developers find extensions that have been defined, both classical Webauthn extensions as well as attestation formats. It allows for extensibility without spec changes.
Lee: Are you saying “these are the only ones we allow and the policies we allow” or is it “this is a registry of known things and there might be more”
Mike: It’s totally up to implementations as to what they implement or not. Apple used the registry to define an apple attestation format.
Martijn: If a registry is the proper way of doing it, we still care about knowing about some parts of the request and we need to do something, or we have no idea of what’s being requested. We also have requirements on protections around the response (e.g., phishing protection). If we go another route, we can get those protections another way, but we need to get these requirements in somehow.
Mike: That’s not in conflict with having a registry.
Martijn: In the spec, some will be part of the registry and you will need to implement those. The registry was doing two things, and we can split those two things, but then we’d need to add things to the spec to define a compliant protocol.
Tim: If you (Lee) think there’s still debate on whether to have a registry, please create an issue.
Lee: It will get resolved on the other issue.