-
Notifications
You must be signed in to change notification settings - Fork 9
2023 12 04 Meeting Notes
Organizer: Tim Cappalli
Scribe: Lee Campbell
- Administrivia
- Canceling 12/27(B) and 1/1 (A) calls
- Intros from new folks
- Updates from Blink incubation
- Anyone prototyping with their wallet or verifier?
- Demo of updated Chrome/Android prototype
- Identity Credential WG naming
- Continue Discussion: “protocol” property
- How to represent “mdoc request”?
- Is a registry needed?
- Support for OIDC and SAML via FedCM?
- AOB
- Orie Steele (Transmute)
- Lee Campbell (Google/Android)
- Tim Cappalli(Microsoft)
- Wendy Seltzer (Tucows)
- Hicham Lozi (Apple)
- Heather Flanagan (Spherical Cow Consulting)
- Rick Byers (Google Chrome)
- Sam Goto (Google Chrome)
- Gareth Oliver (Google)
- Dirk Balfanz (Google)
- Andrew Hughes (FaceTec.com !)
- Benjamin VanderSloot (Mozilla)
- Ted Thibodeau Jr (OpenLink Software) (he/him)
- Martijn Haring (Apple)
- Helen Qin (Google / Android)
Tim: 27th Dec and 1st Jan calls are canceled
Orie: author/editor of VC specs, interested in securing things, involved in COSE
Sam: Updated Chrome canary to match the latest explainer in the WICG github. ARF folks are looking for a public link. Was planning to start writing down a skeleton spec to start formalizing the WebIDL interfaces and algorithms.
Hicham: A stable public link would be very helpful
Sam: Will create this link and people need to submit PRs to keep it updated. Need a process for merging PRs.
Lee: The end to end flow is available. Currently folks would need to write their own matchers. We’ll write a stock one for OpenID4VP
Brian: Is OpenID4VP a protocol?
Lee: Yeah, we’d consider OpenID4VP the request protocol, with PE being an implementation detail within it.
Dirk: Which is the latest proposal?
Sam: https://github.com/WICG/identity-credential/blob/main/digital-credentials-2-proposal.md
Rick: Apologies for the confusing, also sending a PR to update the README
Sam: Pushed to a future call, not ready to demo, but the code has landed in canary if folks to try it.
Tim: WG for FedCM isn’t necessarily right now bound to this work, but the overall intuition is that FedCM would at some point be serving as a baseline. There was feedback in slack on FedID CG that it is a bit confusing
Sam: Are we proposing to rename the FedID CG?
Heather: the confusion is around, there is a phase 1 and phase 2 of the work, and we did not put that into the charter,
Sam: Not clear to everyone (Apple), that this work and the work in the FedID CG will converge. So the proposal is to keep them separate at the moment.
Sam: Feels Apple would prefer a narrower scope
Hitcham: Ack, Can’t predict how Federation and this work will coverage.
Tim: We’re naming groups, not the specs. Doesn’t imply the specs will converge, it's more the people and the organization setup for the work
Ben: We need the people to converge, not necessarily the specs
Tim:
- Option 1: add future clarity text to the existing spec (Heather to explore this with W3C staff)
- Option 2: rename the WG
- Option 3: rename the WICG work item
Tim: three questions: (a) how can OpenID4VP be represented? (b) can a possible MDocs Request be represented and (c) can / should we create a binding for OIDC in the future?
Lee: on layering … there is this API and custom url schemes … pros and cons to both, we believe that the API has benefits … that’s one layer … above it … you have what we’ve been calling “protocols” … it defines the security parameters (e.g., nonces), query languages (e.g., presentation exchange, etc), etc. There are two things that we are discussing, the first is OpenID4VP … The other one is, could we produce a simpler protocol … we think these protocols should be, ideally, format agnostic … So, there is another proposal … a simpler version of OpenID4VP … is there room for a simpler version of this, which somewhat looks like the original proposal (except that it is format agnostic). There are two options that are being discussed, OpenID4VP which has all of the benefits that it has buy-in from regulations, and one that is in discussion with the intent to simplify it (design it under the assumption that the API is the binding). And the idea is that those layers are somewhat independent
Martijn: we also think it is the best approach to define this end to end encryption at the protocol layer … if we have multiple protocols living on top, we don’t need to do security analysis individually
Orie: i see the point of building HPKE at the protocol layer … just to comment on the credential format … i like the idea of having encryption at the protocol level
Brian: my understanding of OpenID4VP is that it crosses all of these layers … I’m not sure where this fits
Lee: in the sections in the OpenID4VP that go over invocation, we’d have an option that would call the Browser API instead
Hicham: orie, did you say that you’d prefer that the encryption be defined at the API level or at the protocol level?
Orie: I'm one of the authors of the COSE/JOSE formats and we know that in some formats, we will be using HPKE and it would be nice to have the API be aware of end to end encryption … I’m in favor of the browser API having an assumption that in order to talk to these origins you have to use X/Y encryption schemes.
Tim: today one of the discussions is the back-channel discussion …. Makes the system more phishable, so we are interested in having that discussion.
Lee: we don’t want the wallet to be unnecessarily revealed to the verifier as part of the protocol
Brian: some things are common but some of it is done that way because there were missing affordances in the browser
Brian: i’m confused by OpenID4VP because it was designed in a way that was constrained by the lack of affordances in the platform
Tim: Next step could be to “red line” the OpenID4VP spec to highlight what was needed for custom schemes vs what would needed when using the web api
Sam: Many of the options there, such as passing by URIs, is because of the limitations of custom URL schemes.
Brian: Would any of OpenID4VP be left here?
Sam: Believes that the best path is to start with OpenID4VP and to modify it to meet the needs of the browser API vs defining something new.
Tim: lots of parallels with OpenID Connect, where lots of stuff in the spec isn’t required once you have proper API support
Rick: We need to assume that many users won’t have access to this API, so we need to design an ecosystem solution which has a backwards compatibility story.
Martijn: Great to get some feedback on the OpenID4VP profiling spec to check if the interpretation that we’re just mandating PE+Nonce and vp_token response and thats it.
Tim: Where can we go have this conversation with the OpenID4VP folks?
Brian: Many of those folks are EU based, different opinions on if this can work well with OpenID4VP or is in conflict with it
Tim: Will plan to setup a call for next week on this topic Next call next Wed