-
Notifications
You must be signed in to change notification settings - Fork 9
2024 06 12 Meeting Notes
Organizer: Tim Cappalli
Scribe: Rick
- Administrivia
- REMINDER: WICG Digital Credentials F2F on 6/21/24 in Mountain View (co-located with joint Fed ID CG/WG meeting on 6/20/24)
- Intros from new folks
- Updates from incubation
- Anyone from Chromium or WebKit have any updates?
- Anyone prototyping with their wallet or verifier?
- Any updates from the OID4VP workstream in OIDF DCP WG?
- FYI: TPAC - Requested Monday 14:00-16:00
- Hybrid meeting agenda building (link)
- Continued discussion
- Wallet-provided nonce (#92)
- Torsten — good to close this?
- Wallet-provided nonce (#92)
- New discussion
- Threat Modeling for Decentralized Identities (#115)
- Should we have a common and interoperable definition of request types and their privacy properties? (#117)
- Should requests be assumed to be linkable by the browser? (#122)
- Access to an Open Global Web Reduced (#123)
- TPAC Planning
- AOB
- Tim Cappalli, Okta
- Marcos Cáceres, Apple
- David Waite, Ping Identity
- Rick Byers, Google Chrome
- Sam Goto, Google Chrome
- Benjamin VanderSloot, Mozilla
- Wendy Seltzer, Tucows
- Nick Doty, CDT
- Helen Qin, Google / Android
- Clecio Varjao, Government of BC (Canada)
- Tobias Looker, MATTR
- Mike Jones, Independent
- Ted Thibodeau (he/him) (OpenLink Software)
- Hiroyuki Sano (Sony Group)
Tim: Reminder about hybrid meeting next week. be sure to register even if you're attending remotely so you get the meeting link.
none
Tobias: status on CTAP 2.2 changes?
Tim: I'm aiming to have PR up before end of June, then a review process
Tim: JFYI - Lee and I did a webinar with NIST yesterday, ~140 participants. Went well. Not many questions for the API itself. It was recorded. I will share the slides.
Tobias: some work on the query syntax. Awarded at EIC for future technologies.
Tobias: Good discussion of query syntax
Tim: Where is the PR for this profile? There are lots of unresolved comments.
Tobias: It's an active discussion, we are working on it. I'll get back to you. It's related to a query syntax discussion we had this week.
Mike: In that discussion, Sam Goto mentioned he expected to only present one credential at a time and would want to optimize for that case rather than the special case of multiple credentials.
Sam: Yes that's the intuition, but in the future we may be able to do more. We shouldn't corner ourselves into not allowing it. Lee is an authority.
Lee: It's just difficult for us to build UX if we have to present multiple, so we're restricting ourselves to one at a time for now. It's hard to orchestrate consents across multiple wallets etc. But it's coming up a lot, people asking for it. Our answer for now is to make two calls with the website mediating taking the user through the flow. But we're using the same APIs in the platform for in-person and we can't say "tap 4 times in person". So we may have to solve this anyway, and if we do solve in-person that gives us a way to also solve online.
Marcos: Agreed on UX side. I'm still wondering if we should plan the request to deal with it. It's assumed to be an "or" in the providers array. Maybe I should file an issue.
Lee: We definitely shouldn't rule it out, it should be flexible enough to do it. Our provider list is an "or", query syntax is "and" — some discussion about that.
Tobias: We've been talking about the default syntax. It's currently and, but could be "or". Then that would be the simplest syntax, but we could have a rule style object to override that says to pick multiple or something. So it sounds like we're thinking in a similar vein.
Tim: could be a good agenda topic for next week
Marcos: Do we think 2 hours is enough? Could we get our own room for all day Tuesday?
Tim: I requested a slot but they said we should use WICG slots. I copied you on e-mail if you want to follow up.
Marcos: Ok, I will. Also I'm chairing web apps on Monday so won't be able to get away from that.
Tim: link, I started filling in some topics and split into half hour blocks. We can be a little loose on timing, but want to make sure people joining remotely don't miss the topic they want. Feel free to add topics to the doc. I will pull out issues, but also hoping we have some higher level discussions with higher bandwidth. Tim: Want to finalize by Monday or Tuesday. Lee: Maybe error codes? We're trying to figure out what errors we'd send. We're thinking any errors other than "user canceled" reveals that there's a credential there which breaks one of our principles. Tim: Lots of negative feedback on WebAuthn on not getting errors, but it is one of the privacy principles. Some work is happening now to give better errors after the user gives permission. Lee: For example, what if RP verification fails after the user has given permission? That's a valid use case. Lee: We've said issuance is out of scope, but it's becoming more and more pressing. We're getting asked about it a lot. Europe LSPs are kicking off and they all require issuance. For now we're saying, "do OpenID4VCI with custom URL schemes, and use our API for presentation," but that's not very satisfying. Tim: agreed, let's do the forward looking things at the end of the day Tim: add things or ping me on slack and I'll post on slack when the agenda is "final".
Tim: Torsten isn't here, perhaps we should just summarize and close this one? If someone from the DCP working group wants to do that on behalf of Torsten that would be great. Tobias: I agree, I'm happy to ping Torsten.
Tim: Was hoping Simone would talk about this, but he's not here so lets skip for now.
Should we have a common and interoperable definition of request types and their privacy properties? (117)
Tim: Sam opened this. Request types like "age verification". We've danced around the fact that we need this, but this is tied in with the registry, who owns schemas, etc. Could be a good F2F topic.
Tim: If UAs are going to use heuristics to put a risk score against some of these, would it be better for them to be more well understood?
Nick: The impression I got was that there wasn't a lot of appetite for it because the web is an exciting place and we don't know the different types. I expect this to be relevant to privacy and exclusion. If I'm a website and I want someone to prove they're over 18, do I have to know every issuer around the world that issues an acceptable over-18ness? Do I have to work out with some consortium how to do this without learning the issuer? We've been hand-waving over this, but we could define some specific use cases such that you wouldn't need to list specific issuers. Channeling Mozilla's concern. I know we can't do this for every use case. But is there appetite?
Sam: I do think there's an appetite. I'd be excited to participate in the discussion. Should we be reactive or proactive? I feel I don't know how things will play out to know the different request types and their consequences, but that might just be me personally. Maybe some we're only going to be able to see in hindsight. If Marcos or Mozilla had a list of request types they know they are going to intervene against in a specific way that would leave to a more concrete discussion. The one that Chrome has so far is age verification requests — just one bit (in addition to the issuer) and it may have a big bang for the buck. Beyond that it's not clear to me.
Marcos: agree we should just start with age verification.
Rick: Has anyone talked to verifiers? Are there verifiers who would use a yes/no signal?
Lee: Don't think it can meet regulatory requirements. If you sign it, it does add more context. For mdoc, it uses the device key and does track it back to you. As soon as you sign something, its not just true/false anymore. Some RPs will say it doesn't have to be government signed, e.g. Facebook saying over 18.
Rick: Same expectation.
Nick: Has to be someone behind it, otherwise its just an age declaration. Should be working towards a huge list and all you know is it was part of that huge list
Lee: can imagine a ZKP of an identity on a list. Wouldn't learn issuer. It's political. Need to build a list, decide who is on it, and does it meet regulatory requirements….
Rick: That's why we need the consortium thing. That is the crux of the problem.
Lee: Could be regional. Could be US and Europe
Tobias: Intersection of regulatory requirements and cryptographic protocols. Have a lot in the cryptographic bag, but requires other parts of the market in order to move
Lee: Can probably do ZKP stuff today for someone like a TikTok, but not for a regulatory body.
Tobias: Taking one of the schemes through the CFRG at IETF. The BBS signature scheme which has some of the properties discussed here.
Tim: If we did some small list of request types to start, could we take it from the inverse approach? These are the types of requests you're less likely to get interference on from the UA (like age)?
Rick: That's the only thing that will be useful. Hunch is that there will prove to be value for that.
Ben: ?
Rick: Relies on the wallets interpreting the bit. Bit unlinkable from other sites, for example. Wallets could offer a more streamlined permission flow. Today, we have no way to know the MSO is being reused, which can turn into RP collusion subverting selective disclosure.
Tobias: re: unlinkability, assuming the wallet is an active participant in preserving a user's privacy, have on time use MSOs, including one time use device keys. Could be a topic to discuss along with ZKPs.
Lee: Maybe age is so special, that age should be a top level in the API, in addition to digital, can build UX around it because we know exactly what it is. Digital is for everything else, the massive set of other use cases. Age seems to be the one that always comes up.
Ben: acknowledge what Tobias said. Looking at the threat model and the intersection between the two user agents. Who is trusted, if it's two user agents working collaboratively, or they're working against each other.
Tim: Lee, isn't the API shape separate? Couldn't this just be adding a 3rd parameter that's optional.
Lee: Maybe, but if you do that it still kind of implies you have the full expressibility. But if mdoc is problematic for age, then we could specify it very precisely — like a single well defined ZKP. But if it's just another parameter, then we have to reason about all the other parameters.
Rick: We can do this additively later. More worried about things we can't change later. Fine starting with higher friction flows for everyone, and then figuring out how to augment things later.
Tim: Interesting thing to me is that the other piece of data in the mDL is the document number that everyone is going to want to have as a unique identifier. That's a worse disclosure. I know age is the hot topic, but it's not the most sensitive. Document number not always being available is the top reason why you can't use mDL for authentication.
Ted: Birthday on its own is not sensitive.
Lee: Two types of data — if you're giving away a linkable identifier then it doesn't matter how unlinkable your protocol is. Then there's the case where you're trying to give away only unlinkable information but the protocol gives away unintended linkable information. The unintended linkable information is the bigger problem. The intentional linkable information is more of a UX problem. We should separate these two buckets. We're worried about breaking a user contract by presenting age as unlinkable if it really isn't.
Tim: Last call I asked Ben to ensure we had issues tracking mozilla standards position concerns
Defer to next week
Nick: Would like to get some feedback on the call. When we have been talking about selective disclosure / potential advantages of the three-party model, the premise has been that it's possible to do unlinkable presentations. I understand there could be side effects that undermine that. But if we're not going to try to provide unlinkable presentations at all then this seems like a very different API and we should stop talking about the advantages and admit it's like showing your full driver's license every time. We really should be able to answer this question.
Tobias: We absolutely have to hold to these. Selective disclosure and unlinkable presentations are different things. When we say "selective disclosure from my drivers license" it's still revealing that it's a driver's license. Unlinkability is an entirely different property, they aren't the same.
Nick: I have been thinking of them as a dependency. We're giving up the game if we're providing a unique identifier when we say we’re selectively disclosing one property from a credential.
Mike: Regarding whether we should have a presumption of unlinkability — in general, it's not knowable, unless you understand the credential format and cryptography used, and that's going to continue evolving. We have to assume we don't know. For instance, to use the BBS stuff in the JSON world, you'll probably use JSON Web proofs (which isn't done), but then you can have proof of knowledge of certain things. But you're not going to be able to know the degree of information being released.
David: Some of this comes from what threat model you're using, e.g., do you assume verifiers to be malicious in certain ways? If I can't locally verify the message from the holder has never been presented before, and my model is that the holder could be malicious and releasing additional information, then I'm not going to be able to solve this problem via a protocol. The ZKP protocols are made so that the intermediary cannot know if the proof is correct or not. It comes back to ensuring we have a solid threat model.
Lee: For the hybrid stuff, we need to define what the JSON is. For WebAuthn this is easy because there are from/to JSON methods specified in the specs. We don't have that on the digital object yet; could you add it, Sam/Marcos? Then hybrid spec can say the same thing as for webauthn. Then it's defined in the spec how you do the conversions (e.g., bytes to base64).
Tim: Yeah, that would simplify it.
Lee: Could just copy how webauthn does it. Would be really cool if we could put it in the base credential request so that any credential could be serialized over hybrid.
Marcos: Please file an issue
Tim: Ok, I will. I worked with Matt on the WebAuthn one so it's top of mind