-
Notifications
You must be signed in to change notification settings - Fork 9
2023 12 18 Meeting Notes
Organizer: Tim Cappalli
Scribe: Rick Byers
- 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?
- Continue discussion on the Identity Credential API binding for OpenID4VP
- Do we really need publicKey to be outside of the request property?
- AOB
- Tim Cappalli (Microsoft)
- Lee Campbell (Google/Android)
- Martijn Haring (Apple)
- Mike Jones (Independent)
- Wendy Seltzer (Tucows)
- Hicham Lozi(Apple)
- Brian Campbell (Ping)
- Rick Byers (Google Chrome)
- Ben VanderSloot (Mozilla)
- Orie Steele (Transmute)
- Sebastien Bahloul (IDEMIA)
- John Bradley (Yubico)
- Ted Thibodeau Jr (OpenLink Software) (he/him)
Next call Wed Jan 10th, B call
Sebastien: joining from France as an individual. Working on MDL space, member of WG4/WG10 in ISO Gail: executive director of OpenID Foundation. Looking forward to conversation
Tim: Last call (B), loose consensus that binding profile should happen in OpenID. Right people there, less paperwork.
Tim: Looks like Brian (or someone) talked with the group. Kristina mentioned they'd be working on finalizing an implementer draft next 3-4 weeks so won't be able to drop everything, but would like to start looking in mid-January.
Tim: Meat of work seems to be in that profile. We still need to work on the API shape here. Do we want to keep both calls on the schedule, or move to one call and have folks join OpenID call?
John: Enough work going on in OpenID calls, that we probably want to keep these for the near term. Not sure how much bandwidth we'll get in the OID forum given all the requirements in the EU, etc. Wouldn't want to drop the amount of bandwidth we have here.
Tim: For John, Mike, and Gail — Would it be a valid path to start work on that document here and give it to OpenID Foundation?
John: It needs to be contributed to the OpenID Foundation. That's harder if we have sketchy IPR provenance on it. Right now Lee has a Google doc where IPR is clear; Google could contribute it. Mike?
Mike: In 2007, we had to do a process to collect contribution agreements from everyone who had contributed to OpenID 2.0, in order to make it IPR-clean. Hoping we don't set up a situation where we have to do that again. If only a known set of people work on a doc and contribute it, that's OK
Rick: We can decouple things. If OIDF wants to create a blank document in their repo with their own IPR, people can contribute to it. We can start fresh or contribute to Lee's doc.
John: No problem contributing Lee’s doc and using that as a starting point since it is indeed Lee’s doc
Mike: Not the case that anyone can put stuff into the OpenID doc
John: mutual non-assert essentially
Tim: Want to make sure it's clear the goal is not to write a new spec, but to create a profile of existing OpenID4VP. Goal is not to create net-new content.
Martijn: No idea what a potential timeline is for Apple signing a contribution agreement.
Tim: Is it only for people committing to the Github repo or also discussion?
John: If you're contributing ideas of any form — spoken, written, github, etc. — we can only use them with IPR commitment.
Martijn: Need to be mindful that there might be issues to be aware of. Don't read anything negative or positive into my statement.
John: But risk of contributing here is no IPR commitment
Rick: Responding to John, WICG does have an IPR policy. Understanding is that ideas contributed to WICG come with an IPR grant to those ideas.
John: Are CGs supposed to do spec work?
Rick: Not producing standards-track documents, but often produce ideas that become standards-track documents. Browsers have shipped APIs based on draft community group reports.
Tim: Can we address this with a liaison agreement?
John: Don't believe W3C and OpenID have a liaison agreement but that could be rectified. But that doesn't necessarily handle the IPR transfer.
Gail: Quick answer is liaison isn't in place. Obviously happy to help with diligence for Apple or others who want to evaluate OpenID IPR policy. Super standard. No costs to contribute. Everyone has the same terms of IPR. Open offer to help support.
Wendy: As Rick noted, I was W3C's counsel for a long time but no longer represent W3C (now at Tucows). Community groups including WICG operate under contributor license agreement which has patent commitments. Also an option for community groups to go further with a final specification agreement when they move a spec on to other development, that is more in the shape of the commitments that participants make in W3C working groups. The distinction is between commitments on things you contribute to the work vs. commitments on essential claims, based on anything anyone contributes to the work. On the topic of liaisons, there are times when this involves joint publication of work, e.g., between two standards organizations with cross-participation and approval. If that is something of interest, it could add even more complexity. Various flavors of coordination. Happy to share contacts with W3C staff.
Tim: Recent example of something that followed that pattern?
Wendy: Early WebAuthn did that with the FIDO alliance.
Tim: Might not help with short-term expediency; might be something we should evaluate. Does Mozilla have preference?
Ben: Don't know if we're members, not sure who would have context.
Tim: So what's the conclusion? We could continue working on Lee's document in this group for the next month, and worry later about how to transfer?
Gail: I think that's reasonable short-term and could help us while we explore other options.
John: I think Kristina's request was to have Lee's document contributed. We should at least track contributors to Lee's document if work is going to be done on it. So those people could later make any needed IPR commitments if the document is contributed.
Tim: Can you revoke the "public editor" role and make it "suggesting"? Rick made it public.
Rick: Probably best to just put it into WICG github; then all contributions are tracked and blocked on signing contributor agreement.
Lee: Last time I said I'd write a better doc and make it more like a profiling spec. I'll try to do that by the next call in the new year and I'll put it straight into our github.
Tim: Any other topics?
Lee: Reason that seemed to resonate with folks was that we wanted to be able to enforce in the spec that there's origin binding. We can do this by mandating that the origin is put inside HPKE. If you don't have it there, you have nowhere to put it other than vague "hope that inner protocols do some sort of origin binding". Also we wanted some kind of insurance that browsers didn't see the reply and that would encode it at the protocol level. Doesn't actually enforce, because you can't guarantee the browser didn't MITM, but it still gives you some confidence.
John: Don't object to having it there, but the key that's used to encrypt the response back might not be that key depending on the sophistication of the wallet. The protocols already support encryption, and there are existing methods for getting the keys which aren't passed in the request. Existing metadata verifiers have through federation metadata or well known locations.
Lee: I was on the fence of letting encryption be part of the inner protocols. But I am somewhat swayed by needing a place for origin binding.
John: I'm not against having it there. But the wallet and protocol may wind up getting the key in a more secure way.
Hicham: I disagree with Lee on one thing — there are ways to ensure the browser isn't MITMing it. In general, we don't want different crypto protocols for different mechanisms because it makes it harder, e.g., to ensure it's secure. Much easier to define a common for all protocols. Ensures a consistent approach to encryption. Can help simplify implementations and reduce risks. Having that public key outside is one of them and may help in the idea of not having the browser MITM it. You can do stuff to ensure that encryption is E2E between wallet and RP. We feel this is quite important to define the API layer.
Orie: Having many different ways to discover the recipient's public key will be really painful. Prefer you can always bind to it with well defined limitations, like crypto details. How many different ways of representing public keys do I have to support, especially if I let you discover it in a million ways and it can be many different things? I don't even like that it's a DOM string.
Rick: Hearing the argument that the browser reason about the < >; wallets may want to discover the key a different way. Not necessarily incompatible. Had a scenario where the key was mismatched between the one passed with the browser API and wallet discovery would be a failure.
John: Haven’t thought about all the possible use cases but sounds fine. There is a requirement for the wallet to validate who the verifier is. Typically done through federation metadata or information from the ??. Maybe if there was a PKI trust chain to walk, that could be a way to do it, but not sure that should be baked into the protocol. Having the encryption key and allowing people to validate it seems to be reasonable.
Rick: Could maybe define it in browser API spec as possibly redundant, but never contradictory?
Mike: Having one way is always superior to multiple ways. We should be choosing one and expecting everyone to do it.
Hicham: I agree with that. We called it public key but depending how we define it, it could be something else like a certificate.
Lee: I'd prefer a raw key to a certificate. But I'd put identity binding into the inner protocol and check that the hashes match at that level. Otherwise we'd have to spec full X.509 cert chains at this level. Better to leave that to the protocol. My intuition is not to pile too much onto the outside protocol around identity and PKI.
Tim: One piece of the question is whether it should always be required.
Mike: Yes
Lee: Feels like no point if it's optional. To Hicham's point, only get the value if it's required.
Ben: Somewhat tangential: assuming credential request blob would be legible to the browser, so the browser could understand and take action to adjust friction. Is that consistent?
Lee: Yes, saying we need that for our design.
Ben: Terrific, sounds like a best case scenario to me. Would be better to specify structure per protocol instead of DOMString blob for the entirety of the request field
Orie: Saying HPKE is being used isn't detailed enough, need more details to get a consistent response. Things like "response mode". Is it intentional that response be fully opaque and bound to higher level HPKE, or is it application layer HPKE?
Martijn: Agree with Orie, important that we fully specify this. We know what the security and privacy considerations are when returning a blob in an E2E way. We should fully specify that, including the exact mode, how it's encapsulated, all those details. Underlying protocols don't have to worry or care, making it easier to support different protocols. Agree that we should fully specify that.
John: But it's not the browser doing the encryption
Martijn: 100% agree, browser should not be involved in that.
John: But it needs to be flexible enough to support post quantum, all the different curves for the Germans, maybe different optimizations for VBS. So yes it should be as clear as possible, but we need to also have appropriate encryption agility to support various regulations. E.g., Chinese government will have their own opinions.
Orie: HPKE registry has a minimum requirement. When you get into the application realm, browsers might be able to learn interesting information from the optional fields. If application-layer encryption is allowed, it's possible the browser could look into that and see structure beyond just raw HPKE response.
Tim: So: Public key should be required at top level, more specific than DOM string, may be redundant but not contradictory, and ….
Lee: Can we add, must solve the origin binding problem?
John: But this doesn't solve origin binding.
Lee: But you have to sign something with the origin in it somewhere; otherwise, you can MITM. Could say the underlying protocol must do it somewhere (like session transcript in MDOC). Or could mandate at the top level like in the AG? Field of the HPKE.
Hicham: By origin binding, you mean device signing? Still need to let protocol and format do something. Definition of API should allow it; protocol should add it. Still binding between device key and response encryption, but it is protocol and format specific. We're playing in that line that we need to allow the input to allow the wallet to do that binding, but don't want to define it here because we get into protocol-specific.
Lee: If we didn't have this we'd just say every protocol must define some origin binding, and that would be fine. Or we could enforce it, so the device key used on the other side of HPKE was signing over that and guaranteeing the integrity. Any implementation not putting origin in AD is not compliant in some way. I was happy with the first TBH, but was semi-swayed that putting it at the top level ensures protocols can origin-bind in HPKE.
Hicham: I think it's fair enough that we can put in our spec that we mandate that origin is signed in the underlying protocol. The way it's done in mdoc is going to be different from how it's done by VC. We can put that requirement there that it's part of how signing with the device key works.
Ben: One example is the DOM string public key. Just because a spec is liberal enough to accept stuff, doesn't mean we can't put requirements on it. We can also say that the browser passes the origin to the wallet and would only permit protocols that have this origin binding. Leaning more on spec definition than type of arguments in API.
Tim: Since we're saying you're going to need a profile or spec text in order to be included in the registry, do we need the equivalent of a client data hash? Even if only origin today? E.g., from WebAuthn?
John: We would need to define what is the information in the metadata we're thinking of returning from the user agent that you would want signed over without telling the wallet what it is.
Lee: We don't mind telling the wallet what it is. Ultimately we just want the origin.
Hicham: maybe also a nonce
Lee: Yeah
John: Should be a challenge, part of most protocols now. The wallet needs to know what the browser's view of the origin is. In the API, it must receive that in a trustable way so it can look up the federation metadata (well_known), check that the key it's supposed to encrypt to is legitimate for that origin. If you can fake the communication through the browser and give it your public encryption key and the original domain, you can decrypt it. You have to validate the origin against something. Throwing a raw key in there without validating it against something isn't going to help with preventing an attacker from decrypting it.
Tim: So we still have to define something in a predictable manner that gets this data from the web platform downstream. That's ultimately proprietary. But should we define something like client data from webauthn?
John: Putting in a placeholder like a hash of the json object isn't a bad idea. But I'm not entirely sure. We have various things in webauthn client data that mostly relate to the origin, wallet ID of the native app that's invoking it. Some information that the verifier can use to check to ensure nothing bad has happened. Maybe we'll come up with stuff like that we want to pass back.
Lee: Should we put that in the proposal then? That it could be client data?
Tim: Not sure if it's directly related to HPKE stuff. But I'll create a separate issue about whether we need client data.
John: Wallet still has to do something to validate that it's the right key for that origin. Maybe a certificate or JWKS.
Lee: We're looking at some ZKPs and presenting mdocs with ZKPs. By definition the traffic is encrypted. So doing an extra level of encryption on top makes it harder — doing ZKP under that encryption layer. One of the reasons for doing the ZKP is hiding the device key. But this might reveal the device key.
John: In bad implementations where a wallet isn't generating a random key for its encryption.
Lee: But that's the normal case for mdoc, right?
John: No shouldn't be. There's a proof key used for signing, that shouldn't be the one used for encryption.
Lee: aren't there different modes?
Hicham: think there are two different conversations
Lee: If you're using ZKPs for presenting, this layer of encryption may not help you, and reveal more than you need to because you're putting another key into the mix.
Tim: sorry to cut conversation. Please don't join this call early as 60 min timer kicks off. Thank you, happy holidays.