2023-12-13 (B Call)

Organizer: Tim Cappalli

Scribe: Heather Flanagan

Agenda

• 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?
• Identity Credential API Binding for OpenID4VP
• AOB

Attendees

• Heather Flanagan (Spherical Cow Consulting)
• Dirk Balfanz (Google)
• Rick Byers (Google Chrome)
• Tim Cappalli (Microsoft)
• Lee Campbell (Google/Android)
• Benjamin VanderSloot (Mozilla)
• Marcos Caceres (Apple)
• Tobias Looker (MATTR)
• Brian Campbell (Ping)
• Helen Qin (google / android)
• Wendy Seltzer (Tucows)
• Kyle Den Hartog (Brave)

Notes

Identity Credential API Binding for OpenID4VP

(Tim) on the last call, we agreed to "red-line" OpenID4VP to mark up things that would not apply to use in a web platform API. Lee took a pass at that; Dirk is going to review on the call. Link

(Dirk) last meeting, we said the API we’re looking at is a good approach and also that we should fit this in the OpenID4VP framework. Because in eIDAS ARF that’s the standard being mentioned. An API invocation of a wallet using OpenID4VP is a good idea. Two things need to happen next: the spec itself needs to add more flexibility. E.g., see section 7 Wallet Invocation, it says there are 3 ways to invoke wallets. We’d need to see a fourth way added, through an API.

(Marcos) should we start in a different direction? Do we want to specify 4?

(Dirk) I don’t think it’s on us to say no one can use OpenID4VP with a custom URI

(Marcos) right, but on the browser side, we want to avoid custom URI schemes in general

(Dirk) yes, the second things to happen is narrowing down the spec into a profile that would provide the API profile that narrows down those options to just API invocation. For this profile, you would have to pass information directly, not the custom URI scheme (as an example).

(Lee) the draft doesn’t exactly match the naming right now; it needs to be updated

(Dirk) Section 6 specifies how responses going back, and this proposal in the profile would explicitly call ou thow to do this in the API (but that would require updating the spec as well). Finally, cross-device flows - hybrid flow has an unphishable flow that’s very similar to what the cross-device flow looks like today. The UX is much the same, but under the hood there is better security properties. The API invocation flow would subsume both same-device and cross-device use cases.

(Lee) I wrote this back in October to kick off the conversation. It needs to be updated. We need to go through PE as well to profile and write a proper doc. Ultimately there’s not that much you’d need to change. Auth request options would need to be limited, for the response you’d need to directly reply. We made need to leave some Zero Knowlege Proofs use cases in that allows a bit more back and forth.

(Dirk) one of the discussion points was: what if the RP wants to open a connection to the wallet? Another response type not mentioned in the spec or in our doc would be to allow the wallet to return its own URI or something.

(Lee) I left that because I think we discourage that so it doesn’t leak the identity of the wallet.

(Dirk) OK.

(Lee) for most of our use cases, we’d return through the API and that’s what we should push for. There is a ZKP that allows two round trips as a possibility, but mostly we should focus on that one round trip.

(Tobias) Thanks for this. As a co-author for OpenID4VP, initial reaction is to really support wanting to reuse as much as possible in that spec rather than reinvent. But OpenID4VP is built on OAuth2, which was built on redirects. Some of the things in OpenID4VP we’d have to be very careful about what to bring in, like the coding of some of the request parameters. What constitutes a client in OAuth doesn’t look like what we’re thinking of here. I would stress that we only reuse the components in the OpenID4VP spec that make sense.

(Dirk) would like to go through the spec to examine all of it in detail to see what we do/don’t need

(Lee) most of it does go away; you’re mostly left with PE. But since it is required by eIDAS, need to use what we can

(Marcos) the exercise of the minimum set of things we need from that spec and restricting to particular formats is critical. Concern remains that OpenID4VP doesn’t limit the number of formats. This is going in the right direction to red line the spec.

(John) Agree this is a good start. Agree with Tobias; things that don’t make sense for this kind of transport should be left out. OIDC and OPenID4VP live in the real world where we deal with browsers and balancing what to do to make it more secure given what’s available. The tension may be what kind of communication, other than through the browser, the wallet and the verifier may have. There are various reasons why direct presentation might be required (e.g., see Germany use case). At the end of the connection there should be something going back from wallet to browser so browser can close the connection.

(Rick) Makes sense. What does deployment look like in practice? An RP will want this to work in browsers that do/don’t have the API. Ignoring the politics side, we want to make it easy on the RP by minimizing the ways they have to support.

(Tim) We’re never going to be able make a super easy hybrid solution. There will always have to be a fallback to what there is today. ON the topic of where this happens, would like some guidance on that. Is this a binding for OpenID4VP, it should be defined by OpenID folks with influence from this group. W3C hasn’t traditionally defined profiles for other SDO’s specs.

(Tobias) conceptually that makes sense. May h ave other solution options with OpenID that might help with the ARF stuff. Where there is conceptual overlap that doesn’t add unnecessary constraints to browser UI (e.g., query syntax can be agnostic, request syntax can be reusable as well) OIDF can talk about that.

(Sam) arguments worth noting for why this approach is a good idea: first, really useful to reuse all the security analysis used in OpenID4VP. Starting from there and removing things that aren’t needed is easier to reason than the reverse of starting from scratch. From an expertise perspective, plugging into that community that’s thought about these problems so long would be helpful and make our work better. So, generally supportive even if it means the profile is extremely small.

(Tim) figuring out where the cut line/transformation line is, is the point. Whether you’re passing the request URI or the entire object, do we need to change more than that? If we de-reference the request URI?

(Tobias) a lot of stuff in that JSON object that is ultimately de-referenced are OIDC and OAuth concepts. The web browser will provide the origin to the RP, that’s the RP’s identity that makes sense to the web. That’s how WebAuthn has done it. A subset of that data in the URI is the request syntax. The outer wrapper of information is the protocol details that maybe able to be stripped.

(Tim) the origin is the statement about the session. Is it being used by anyone else or is it 1:1 with client ID?

(Tobias) the concept of a client in OAuth serves several purposes, e.g., negotiation purposes. Importing the OAuth client and saying it’s going to be broadly applicable is probably not correct. There’s probably a simpler model in the browser context. We need to think about this further.

(Tim) in the case you have to fall back, there’s no harm passing through the client ID on top of checking the origin, maybe?

(Rick) would it make sense for those in the OpenID group to propose a refactoring of the spec into two specs, one that’s the piece in common with the browser, and one that’s specific to OpenID4VP?

(Tobias) it needs broader discussion with the OpenID community. Generally, that’s the way we’ll be a solution that works for the browser rather than trying to be a pipe for a protocol developed elsewhere.

(Rick) feeling urgency and time pressure. Some people are suggesting something simpler that could be done in parallel (and presumably be done faster).

(John) there are only so many people that are expert on this. Trying to divide them on two projects is more likely to lose them from both. Anything going through the W3C will take about a year to become a standard. Maybe it will go faster in the OIDF? That’s uncertain, and a lot does depend on people. We need to look at the purposes for all the things in OpenID4VP before we can strip them out.

(Kyle) collapsing origin/client boundary may not make sense for us. With our model, it’s more arbitrary in a business logic sense. What may end up happening is what happens in the OAUth flow wher eyou hand the token to separate service for validation. LIke KYC is validated by separate platforms rather than verified by every RP. If you collapse the boundaries, you risk privacy violations. So makes sense to keep these separate.

(Lee) if you look at the ARF, each RP needs to talk to a trust authority to get a cert and call a wallet, and somehow they’re going to sign something with the cert. It can’t just be the origin because it won’t just be the TLS cert.

(Tobias) yes, that’s hung off the concept of a client. Need to solve for that element.

(Marcos) we have set up a liaison arrangement with other standards orgs. Maybe we could use that for this collaboration?

(Rick) Google is under an obligation to ship something to users in 2024. They will deploy something via an origin trial, so they can change it, so it will be in production by mid-2024. If that’s compliant with a mature or not mature spec is how it will have to be.

(Tim) nice thing about OpenID, it’s easier to get things done quickly.

(Sam) Do we have a shared sense of urgency with the OIDF? Would they be willing to move as quickly as we need? Are they feeling the pressure with the ARF the way we are? We would need to see a draft proposal within months. If the answer is no, they aren’t ready to move that quickly, doing our own thing becomes more attractive. We also expect the OpenID4VP people to look at our work and make counterproposals.

(Kyle) as a browser vendor, we don’t necessarily want to rush into this. Understand that Google has specific obligations, but we have to recognize the protocol may change. We shouldn’t make the assumption that whatever happens in OpenID and Chrome will be set and cut. It may need to go through a v2 and v3 to make this work.

(Lee) for OpenID, I’ll write this doc. Can we give this a name that sounds OpenIDVP enough that makes them happy, then we could turn that into standard libraries and use it.

(John) the W3C and OIDF have a liaison agreement. If it’s expired, it wouldn’t be hard to renew it. In practice, though, it doesn’t really do much other than get people together to talk more.

(Rick) maybe should talk a bit about who those people are and what meetings we should join? And responding to Kyle about different velocities, definitely agree. From the browser side, expect to be in origin trial. Not sure how that will relate to wallet formats in the pilots. Even when things are shipped, there’s going to have to be a versioning story and support for multiple protocols simultaneously. We’ll be evolving the API while it’s used in production

(Kyle) Makes sense. Worried that if we rush too much in the first person to act, we’ll be seeing a downslope effect. When Chrome ships something, that’s what people will build towards. The regulation needs to settle and we need to push back where needed.

(Rick) expect that actual adoption by end users is going to be fairly slow. We’ve seen this with payments APIs too. FedCM is the same way, too, with a few dedicated partners but a very long talk for adoption (giving us room for breaking changes)

(Kyle) we’re going to work with drivers license and passports initially; nothing that isn’t a non-standard identity card. So fewer arbitrary attributes.

(John) those aren’t the credentials we’re working within the two large-scale pilots I’m working with.

(Tim) one of the challenges is that the wallets aren’t implementing to the web API, they’re implementing to the OS platform API. This is a challenge in webauthn as well. That layer is not standardized and moves very slowly.

(Rick) that’s why Lee has designed the Android API to be very generic. The wallet is what will need to change.

(Tim) would it be realistic to have word from the OpenID folks by Monday?

(Tobias) if you have that doc ready, will share with the editors. The editors call is usually on Tuesday/Wednesday.

(Lee) might have the updated doc by Monday but will try and have something a bit more polished.

(Tobias) it will be difficult to come back with a yes/no as there may be several other options. Will have the conversation with the group.