-
Notifications
You must be signed in to change notification settings - Fork 9
2024 02 07 Meeting Notes
Organizer: Tim Cappalli
Scribe: Heather Flanagan
- Administrivia
- Repo renamed to “digital-identities”
- Updated README with pointers
- Intros from new folks
- Updates from Blink incubation
- Any updates from Google / Chrome team / Apple teams?
- Anyone prototyping with their wallet or verifier?
- PR review: Renamed IdentityRequestProvider to IdentityRequestDetails
- Discussion: Registry inclusion criteria
- Discussion: Do we really need publicKey to be outside of the request property?
- Any further discussion on this one or can we close it?
- https://github.com/WICG/digital-identities/issues/49
- Discussion: Using CryptoKey for public keys - what are the restrictions?
- AOB
- Nick Doty (CDT)
- Heather Flanagan (Spherical Cow Consulting)
- Tim Cappalli (Okta)
- Rick Byers (Google Chrome)
- Kyle Den Hartog (Brave)
- Lee Campbell(Google/Android)
- Orie Steele (Transmute)
- Sebastien Bahloul (IDEMIA, listening mode)
- Hicham Lozi (Apple)
(Tim) Many of the usual attendees are attending the FIDO meeting in Madrid and will miss this call. Moving more heated topics to next week.
(Marcos) Renamed the repo to digital credentials in response to previous discussions. README is also now a pointer to more interesting stuff. Would like to have people review the README to make sure it is sensible and has what we need.
none
(Marcos) started landing patches to get WebKit going with respect to the changes being made. Expect to finish those this week. Will then be ready to start working on the request part. Moving the bits around have helped in understanding how to handle credential management and multiple containers.
(Sam) Equally surprised and excited when Ben suggested that. It solves multiple problems. Being able to reuse the class and have a different instance is great. Did start playing with the code base and it seems like a fairly trivial change. Confident we’ll still run into problems, but it is progress. Sam built a small prototype and another engineer will keep that moving. Expect a prototype by the end of the week that will conform to the spec Marcos put up. This is one of the last steps before origin trials.
(Rick) I think this is what Maciej (sp?) was suggesting many months ago. Should check!
(Tim) any wallets or verifiers have work they want to share? n/a
(Rick) was going a lot of VPN’ing to Europe this week and got to experience the age verification process when creating a Google account. It’s awful! Looking forward to improving that.
(Tim) Would love to have this on a screen recording!
(Ben) Thanks to Marcos and Sam for taking the feedback on the proposal and moving it forward.
(Marcos) On the Mozilla side, will there be implementation tests so we can have engine discussions?
(Ben) would be great to have a chat log to help this happen in a semi-public space.
(Tim) maybe two new channels (UA dev, verifiers-dev)? Will figure it out.
(Sam) Process-wise, should we block PRs for normative review?
(Ben) no, Marcos and Sam are an engine each.
(Marcos) Having the independent credential containers is the main thing, having them hang off identifier identity. The name may change. In terms of how it works in the spec, we don’t have the request side yet. With credential management, we can define the behavior when calling GET or store. The spec at the moment doesn’t do anything; now is the point where we start looking at that. We need to go back and reflect on whether we need a permissions policy (how does this work with iFrames? Can it work with third-party iFrames?). There is an open issue about integration with credential management which is where the work is happening on this. Two parallel tracks: credential management integration and requests. There are still societal implications to consider which suggest we need to be very careful.
(Tim) thinking about the next 1-2 months, maybe have Marcos, Ben, Sam run with the PR and discuss the societal implications on the call?
(Marcos) Want us to be cognizant that we’re not just plowing through without considering those implications. Don’t want to send the wrong signal. There are significant road blocks and milestones on the privacy and security side.
(Tim) Understood, but trying to balance that the details of credential management is of interest to a subset of the people on the call. Maybe rely on Marcos, Sam, and Ben to raise issues as needed?
(Marcos) let’s timebox the credential management detail discussions so we can spend the majority of time on the bigger picture.
(Tim) ok. Hope to get to the more controversial ones on the next call.
(Kyle) There are concerns; part of the issue is that without the tech proposal, it’s hard to address how we solve these things. So we have to manage expectations. For example, integrity assurance got a lot of backlash. Need to note that Google has requirements in this space because the regulators have set the rules.
(Ben) A lot of the cred man stuff is in the weeds and not worth surfacing here, but there are issues that will need the larger group where they have implications on policy or how they interact with other layers. (Sam) Agree we should time box details of cred man. Also agree that there are product decisions that are limited by design shape. Note that with the formulation we have, might not be able to ask for both a passkey and an mDL. There are consequences to the UX based on these choices, so don’t de-couple too much. The API frames the products we can build.
(Kyle) We’re also all going to run into key management issues. That will have profound implications esp. with safety in multi-device flows. Understanding the key management will have implication on the top layer that is exposed; need to make sure it’s interoperable.
(Tobias) It’s an interesting concept; we need to draw boundaries around scope. FedCM doesn’t concern itself with implementation details for every IdP. Some things like how a particular provider decides to sync across devices would be out of scope.
(Kyle) The difficulty is, as with passkeys, the management of the key. It’s tied between the user and the RP; the RP needs exposure to that key or recognize that different keys are linked to a user. Do we set conformance standards around how we manage these keys or do we make it out of scope? Either way, we have to make a decision and that will impact the API.
(Tim) seems like it’s a “sit and wait” issue right now?
(Orie) don’t have anything to say on this one.
(Tobias) are we talking about W3C registries or something else (e.g., an abstract registry, an IETF registry)
(Marcos) we can put it in our spec and formalize it later. It’s similar to an IETF registry. The registry has implications for implementation, including privacy and security qualities because the registry registers the structure for whatever the format is, and that will be defined according to webIDL. We can’t just point to another document because they might not be browser-engine compatible.
(Orie) the original issue is that there was a registry defined in the original PR and I wanted to know what the criteria was to add to that registry. This registry out to be a W3C registry. IANA registries can do a “specificaiton required” but it will probably be better to be a W3C registry.
(Tim) anyone willing to take a first stab as to what the requirements might be and add the list to the issue? We need the criteria before we figure out the home for the registry.
(Marcos) We won’t need this in the next 3-4 weeks.
(Sam) don’t know that we can know what the criteria are yet. We need a few more submissions before we find a pattern. It’s not so much the security properties of the system; it’s the maturity and adoption level (e.g., does it show up in regulation). In terms of protocols, what comes to mind is OpenID4VP, and can’t think of any others right now.
(Kyle) GNAP was talking about being able to issue and verify credentials, but not sure of the status of that work. CCG may also be interested in the HTTP API approach coupled with CHAPI. Also, a mobile-specific flow to communicate between applications and browsers.
(Tim) OpenID4VP will be on this list, but we need to backtrack what the important criteria were that led us to say “of course OpenID4VP is on the list.” Things like selective disclosure may need to be a consideration for the API surface.
(Marcos) and we want mdoc in there as well.
(Sam) maybe a terminology exercise, and that’s why it’s important to talk about what’s a protocol. mdoc is a format, not a protocol. OpenID4VP can transport mdocs.
(Marocs) we need a dedicated meeting just around this and will need more than a few hours.
(Tobias) to draw an analogy, maybe it was the mobile document request API that encapsulates mdoc as a format. OpenID4VP has a syntax and as a protocol supports mdocs; the mobile doc request API makes more assumptions about the environment. Agree we need a dedicated call to sort out what we mean by “protocol”. Does it include format, syntax, other? The biggest one for me is that it meets the expectation of the API surface, that you can call a data structure and get a response back (not get back a URL that redirects you to something else).
(Kyle) We’re going to run into a problem that some formats support more feature sets than other. Example: revocation. The data model and the protocol bleed into each other around this. There is a coupling that breaks the abstraction.
(Marcos) Whatever format we work with must not be open-ended. That’s one of our challenges with OpenID4VP.
(Tim) the idea of having a dedicated call for this is a good idea, but don’t want a separate time. Maybe extend this call by an hour before and/or after.
(Marcos) Should consider in a month or two getting together physically somewhere.
(Tim) IIW is an opportunity. (https://internetidentityworkshop.com/)
(Sam) IIW would be good. A lot of the people we need are there.
(Kristina) I was trying to understand we talked about earlier in the conversation is supported, when the public key is passed by reference rather than value, is there a rule about how someone should obtain the key? The browser API can’t open external URIs. Want to clarify that scenario?
(Tim) A question I had on this: in what scenario would the verifier only pass a reference to the verifier?
(Kristina) there are implementations that want to use OpenID Federation that want to get the key from a URI.
(Tobias) not to tie issues together, but it comes down to how the wallets or providers validate who the request is from. If we’re relying on the web origin model like Webauthn, and the browser verifiers the origin, then a lot of these requirements for resolving keys out of band by URL fall away. A lot of these things are required when using browser redirects and you don’t have a browser able to make an assertion in the middle of the flow. Why do we need something more complex?
(Kristina) We do need to decouple authenticating/establishing trust in the RP from passing the public key. They are different assumptions. It’s not just the browser.
(Tobias) Trusting the browser to identify in the context of the web (i.e., supply this as the origin). If the browser can’t be trusted for that responsibility, there can be an additional chain. But it’s still up to the verifier as to what they agree to trust. The RP has to be identified in a consistent manner, and the browser is in a good position to do that. If you can’t trust the browser to do that, we have more problems.
(Kristina) it’s not about not trusting the browser. If there is an origin the browser can use to consistently identify the verifier, that’s fine, but not sure how that relates to the “keys by reference should not be supported” argument.
(Ben) want to point out that while browser can provide some guidance on TLS trust stores and how browser roots of trust work, should not perfectly couple that with how a government identity might work.
(Tim) is it safe to say the public key attribute has no relation to the origin or TLS session in the browser? Have we written down the purpose of the public key attribute?
(Sam) should that be at the browser layer or the protocol layer?
(Kristina) yes, OpenID has that capability.
(Hicham) we should rename it because public key is creating confusion. Trusting the origin could be provided by the browser to identify what the user is visiting. That public key can pass down to the wallet to do both the encryption and authentication. If there is a trust framework that could be dependent on each credential and issuer, the wallet could do that. It’s not going to just be a public key; it depends on teh protocol.
(Tim) if we only tie to OpenID4VP then we don’t need this.
(Sam) this is a conversation between a wallet and a verifier. What does the browser use the public key for? Does the browser ever use that key?
(Hicham) Agree. The idea of having it in that layer is to specify how to do the end-to-end encryption so the browser can’t lock into the response. We have had that discussion and we took the public key from that layer.
(Sam) in the last PR Marcos merged, it doesn’t have public key in that dictionary.
(Kyle) the way I can see this done is if the browser is doing the key management. If the browser acts as an interface to the key storage layer, and the wallet interacts with a different layer, the browser can act as a pipeline layer the way didcomm envisioned it. The browser would act as a semi-client to the OpenID4VP layer. This is why I am bringing up the public key question.
(Tobias) One of the things we have to satisfy around what can be opaque to the browser is a discussion about the negotiation model. What capability and negotiation will the API create? A browser API affords other opportunities we should consider that will effect what’s visible to the browser.
(Tim) Let’s continue this conversation at IIW if at all possible.