-
Notifications
You must be signed in to change notification settings - Fork 9
2024 10 07 Meeting Notes
Organizer: Tim Cappalli
Scribe: Manu (Nick for brief support)
- Administrivia
- Next call (2024-10-16) is canceled due to FIDO
- Intros from any new folks?
- Any updates from incubation?
- CA DMV hackathon?
- Any updates from the OpenID DCP working group?
- Progress on query language?
- PR Review
- Update explainer to include feature detection and new syntax (#173)
- Discussion
- Issues without owners triage: https://github.com/WICG/digital-credentials/issues?q=is%3Aissue+is%3Aopen+no%3Aassignee
- AOB
- Tim Cappalli (Okta)
- Ted Thibodeau (he/him) (OpenLink Software)
- Nick Doty (CDT)
- Wendy Seltzer (Tucows)
- Benjamin VanderSloot (Mozilla)
- Andrew Regenscheid (NIST)
- Joseph Heenan (Authlete / OIDF)
- Manu Sporny (Digital Bazaar)
- Mohamed Amir Yosef (Google Chrome)
- Heather Flanagan (Spherical Cow Consulting)
- Hiroyuki Sano (Sony)
- Simone Onofri (W3C)
- Helen Qin (Google Android)
- Brian Campbell (Ping Identity)
- Lee Campbell (Google Android)
Notes from TPAC are posted.
Next call is canceled for FIDO.
Charter updates?
Simone: integrated all the non-blocking comments. The breakout session was successful. Formal Objection is proceeding with a Council.
[ none ]
Tim: Any updates from incubation? Any updates from Hackathon?
Lee: Sam was the judge! He might be best to provide a summary.
Sam: DMV Hackathon — it was wonderful, Gail was around, Manu was around, it was cool, I personally learned a bunch. A lot of excitement, Lee's demo went well. MATTR did a demo, DMV licenses, personally surprised at how many demos were "log in to website w/ CA DMV DL". It's partly difficult, interesting, and worth talking about as a group.
Lee: Majority of them, I think. Lots of login examples, account recovery, user verification. 2FA, password plus DL, all bucket of login/account recovery. Part of that is stable for the rest of user's life unless you ask for another one (DL). Another takeaway is, nearly everyone did custom URI schemes, custom URI codes, custom stuff, we could drop API into every one of those, reassuring, net improvement over every demo we saw. Cross-device flows consistent and not phishable, drop in pretty well, some did implement API, MATTR demoed it, Australia did, but inbound interest to use API is high. Most came up to them, changed demos to use DC API. Lots of talk about unique IDs, privacy concerns, side discussions on pros/cons. If we had some nice ZKP, be able to tell RP that person has a DL and the same person that saw last time, directed so no RP linkability. If we had some magical ZKP that gave us that feature, it's much reduced. Some people presenting had everything anyway — banks have that information already, probably not a huge privacy risk.
Manu: Strong demand for digital credential API. +1 that implementers were just defaulting to using the strongest identity. or banks using an identity for a KYC. depends on what tooling/feature is available to the developer: many of these things by default had access to all the information on the driver’s license. PoS vendor demoed unlinkable proof of age rather than full driver’s license or full birthdate. A lot of work to nudge these organizations in the right direction. But there are a lot of use cases around KYC where legal compliance requires knowing who the user is.
Wendy: All sounds interesting and as though there are lots of people we could share some privacy guidance. Is there a public write up or other information available?
Manu: CA DMV not sharing for the participants themselves, although many participants have talked about it publicly. any public feedback from this group would be input to CA DMV and the relevant agencies. Vendors can then point agencies to the advice of the privacy/security community.
Benjamin: In the open loop model, there is probably subtlety on KYC, going to CA DMV website is a reasonable use case. Login scenarios are generally terrifying where you use DL for sign in to not strictly necessary to login seems like a bad idea at this stage.
Manu: we will provide that feedback directly to CA DMV and policymakers.
Tim: Can we move some of this chat discussion live so its in the minutes? I'm seeing in chat: Don't conflate sign in with sign up. Passkeys, have a part to play.
Sam: Manu, Lee, and I had an interesting discussion at the event — also talking w/ Mike Jones, don't know words to use yet. Manu introduced me to a term that was insightful, login on the web, user accounts and all, all accounts are anchored into something like a primordial or root identity, and those things turn into derived identities. Login on the web today, most part, email or phone number verification — in practice people create accounts w/ email/phone. There is enough of the segment where people will have root identity, create root identity and move it into derived identity. Anchored in real world in some way. Arguably, social is rooted in real person. That's where a lot of the Digital Credentials aspects fit into place. Government issued identity is in that space. The second you have these root identities, you trade them very quickly for a derived identity — passkey or cookie, you keep translating awkward-to-carry things to easier-to-carry — wanted to represent the discussion — passkeys play a wonderful role in derived identity. It's not clear if they're recoverable as root identity, maybe they are, but perhaps the separation seems to make sense. When people say: We shouldn't use credentials on the web — they conflate sign in with sign up. With enterprises for example, some demos, a company demonstrated being able to recover the account… identify yourself as an employee via CA DMV license (anchored)... you can't throw passkeys at that problem.
Tim: Maybe we should start mapping out these use cases. Workforce, for example, is out of scope — mapping those out and bootstrapping/recovery is different from consumer sign up and over-providing information for form fill. There is a difference between using email vs. strongly attested driver's license.
Wendy: It's an interesting discussion because there are at least 2 models of how people interact as humans. One is this monolithic, you're the same person everywhere you go, but a lot of privacy conversation uses the notion of a contextual identity, unlinkable to everyone except you (law enforcement in case of serious wrongdoing may be an exception). In the contextual model, the notion that all casual web uses are rooted back to specific government identity would be disconcerting. While usability is challenging, helping end users manage contextual identities, I wouldn't jump to assuming they'll be okay linking them back to single linkable issued identity or email address.
Andy: We've been talking about this, sign-up, sign-in, are different, they get conflated. There are some that are interested in sign-in, I've been expecting that won't be practical at an ecosystem level or acceptability level, people aren't going to want websites to use DL number. It's not clear how much we need to address it in the API — maybe you trade these out for passkeys or other VCs held in an RP-specific wallet. Don't know how much it affects the API, this is going to be more challenging to address. More privacy-enhanced, BBS might not be the right way to go, clearly practical quantum resistant way w/o significantly changing crypto that's used with them.
Benjamin: From the privacy analysis perspective, don't care if it's sign in or sign up, it's the same property, link a permanent identifier to a person. If you have an account using password/passkey, then just join — same privacy property. While it is a useful distinction, not particularly interesting in this use case.
Paolo: My question is how is this related to Digital Credential API? This question is an interesting one in EUDI Wallet, provisional conclusion, decoupling when identity is issued for government qualified data, sign up case, we need to provide specific data (qualified/verified) by government, not connected to authentication mechanism. Relying parties choose to agree, different reasons, passkeys, user password, credential recoverable or not, quality of that approach. You might want to link qualified/verified data, where there are overlaps, relying parties requiring LOA on authentication plus data. How is this related to Digital Credential API? Important discussion, happy to continue, what's the angle there?
Lee: Why does this group care? Is that what you're asking?
Paolo: I wonder if there is a specific link in this discussion, or just reporting?
Lee: In the strictest sense, the API as written today isn't opinionated on how you use it. How these APIs might be used, that's why we're interested in it. Different mental models for it. Unintended consequences, steer ecosystem in ways that might be healthy, API isn't opinionated.
Manu: I also think it’s relevant for this group, as well as for ecosystem development generally. and we could provide advice as experts, like ‘don’t issue a Driver’s License without also simultaneously issuing an unlinkable credential’. Not certain yet what this API privacy/security considerations will include. expect browsers to at least warn users about providing driver’s license to a site that may be dangerous, but could go further to something like a qualified verifier. not so worried about post-quantum, not an urgent need but could also address it without too much difficulty later.
Benjamin: From a browser perspective, a lot of the points I was going to say have been hit. Figuring out what uses of API are abuses vs. what should be done or flagged as malicious, outside of the guidance of the APi is useful. Hard to bring it in normatively; we need to confidently ship something that won't harm users.
Paolo: I think the ambition to provide different credential types and reasoning, yes, do support that. Is there a way to contribute? We made a lot of effort to explain this in our community, people get confused about what certain credentials are meant to do, happy to contribute.
Simone: Adoption of Digital Credential API, we're also working on the threat model, from W3C perspective, digital credential API has to consider global threats, warn users/developers. Good use cases vs. bad use cases — otherwise, Manu, Ben, and others have conveyed the concerns and why we might want to focus on this.
skipped
- Nick: Privacy IG is meeting on Tuesday, we’ll have an agenda item to discuss the digital credentials privacy and security implications
Tim: Skipping this for now because CA DMV Hackathon discussion went long.
Update explainer to include feature detection and new syntax (#173)
Tim: Any concerns about the change. Any concerns with merging this?
Sam: Anyone have any concerns w/ PR 173.
Question about meditation from Sam (#149)
Tim: Some background?
Sam: We probably need Marcos for this… Marcos merged spec PR to make mediation=required to be the only mediation we accept. Somewhat makes sense, approved PR and went on to implement it and ran into an implementation problem. Should we fix implementation, or did we get spec PR wrong? Proposal is to allow mediation=optional — some reasons to do that include: backwards incompatibility; developers are not passing this option; credman makes it optional. Should we make mediation optional, go either way, going to propose mediation=optional allows browsers to take it as mediation=required. Implementation could just assume mediation=optional is weaker than mediation=required, browser can require mediation=required. Nice to not have developers set mediation=required. In future, when representing, we could waive some of those things — not saying exactly how it would work, doesn't corner us. Proposal is to accept mediation=optional, happy to be proven otherwise.
Benjamin: I agree that optional is good — developer saying "I don't care if you show a UI or not". Silent is not allowed; leaves choice to browser.
Nick: This seems like a case where the earlier question, API designed for login use case vs. non-login use case, feels like mediation=required should be required, tell site that "This is different from WebAuthn". Auto-sign in might be configured, but presenting DL is not like that, not automatically recognized — exceptional high friction use cases where you want to use a particular credential. Optional still allows one to do that, not like auto-sign-in, recognized use case.
Sam: Javascript API surface, developer option rather than algorithm in the spec. Whether a relying party gets a hint to the browser to require mediation or not. You seem to feel more strongly about browsers always requiring, but this is about whether the verifier has affordance to say mediation=required.
Nick: I don't see what benefit we get from optional.
Lee: This is the site saying "I don't really care" if it's optional. Browsers can decide based on a condition; there is good parity there. Browsers might elect to make it required in the future, proof of age, browser feature for "remember this", pop up vs. present age vs. browser mediating this in the future. Not always high assurance in the future, opens up the browser to make the choice. For now, I expect it'll require full mediation.
Benjamin: Nick makes a good point, point of friction for the developer. Maybe we leave it in. I could go either way.
Tim: No strong feelings, a couple of options — preferred, UAs choice on what to do, what's best for the user.
Nick: Would it be welcome to have a proposal for explaining when it should be required or optional or conditional? Reading spec, hard to figure out? Can we just advise? Under what conditions?
Manu: Making it required can still make it automated, right?
Sam: We won't corner ourselves if we only accept mediation required, it won't corner us from optional. Maybe one way we do this is cross that bridge when we get there? We could punt on this and a future us will solve this in the future? The only unsatisfying part about that, because mediation=optional is default, we will require every user of to do mediation=required, backwards compatible w/ what chrome has. I agree that it's not the end of the world, would be happy with keeping 'mediation=required' and cross 'mediation=optional' in the future if we get to it. I will add to the issue, we're deliberately doing this so we won't corner ourselves.
Lee: This is backwards incompatible for Chrome, just want to make sure everyone is ok with that too.
Add a way to check what protocols are supported (#168)
Tim: Marcos wanted to add protocol feature detection, there haven't been a lot of comments on this.
Lee: It brings up something fundamental about registry, would rather browsers pass this down to platform, so platform supports. Could support an "is protocol supported" test? Problem is you have to update each browser w/ protocols, OpenID want test new query protocol, oid4vp v1.1 — if string said oid4vp 1.1 w/o getting browsers to update, Chrome/Android — if we lock it down to hardcoded list, we can't expand or do anything else, can't change oid4vp to v1.1 w/o updating. Not truthful, pass it through, providing a list locks us into something.
Tim: If it's testing w/ developers or testing at scale, there are mechanisms we could use, if we want it for the masses?
Lee: Origin trial, query new query language, you can do that today — launch pilot w/ wallets/websites — all is good. They need that implementation experience, but if we did this change, they couldn't do that without going and working w/ browser vendor, seems too limiting to me.
Manu: Question around extensibility and protocol ossification. We don't want this stuff to ossify, which it could with just a list. There are also use cases where you might want to use a specific protocol and format in a particular region, even though that would harm interop, we want to allow regions to choose and that speaks to having a "isProtocolSupported()" call rather than a concrete list.
Lee: if you switch to isProtocolSupported, it allows browsers to work w/ platform. If you only support list, you have to agree to list and hard code it, has to be something browser can enumerate given time, tricky on Android, we don't have a way to do that yet.
Tim: Both make sense, static may be problematic.
Brian: This issue seems to have come out of why there are multiple request/data providers allowed in a single request, Marcos filed this because we didn't know what protocols were available, so had to have multiples, but also have this. This might not be necessary anymore.
Lee: When would you use it, request an mDL, two wallets, one supports OID4VP v1.0 and OID4vp v2.0, when you request it, what do you expect, VP 1 and 2, if it does 2, you will miss mDL in first wallet. From a developer point of view, it is useful to query this stuff.
Brian: I'm agreeing with you on that, idea that querying for it might allow single request to be made, simplify API isn't happening, APi still allows for multiple requests, feels like it might be unnecessary line of work. If we are going to pursue it, query by individual yes/no vs. return list.
Tim: Do we need this for first CG report? Depends on Marcos' answer, nice to have later?
Lee: We don't have it now and I think that's enough.
Brian: Agree.
Tim: Anyone on the call believe it should stay in for first CG Report?
No one on call believed it's needed in first CG Report.
Tim: I will talk w/ Marcos about this. Next call is Monday Oct 21st, assigned issues to folks, please take a look at them.