2024-02-12 (A Call)

Organizer: Tim Cappalli

Scribe: Ben VanderSloot

Agenda

• Administrivia
  • Poll for extended meeting on protocol/registry
• Intros from new folks
• Updates from incubation
  • Any updates from Google / Chrome team / Apple teams?
• Anyone prototyping with their wallet or verifier?
• Discussion: Limit access to the API based on known allow listed origins
  • https://github.com/WICG/digital-identities/issues/59
• AOB

Attendees

• Ben VanderSloot (Mozilla)
• Michael Jones
• Lee Campbell (Google/Android)
• Dirk Balfanz (Google)
• Rick Byers (Google Chrome)
• Andrew Regenscheid (NIST)
• Heather Flanagan (Spherical Cow Consulting)
• Wendy Seltzer (Tucows)
• Brian Campbell (Ping)
• Loffie Jordaan (AAMVA)
• Sam Goto (Google/Chrome)
• Torsten Lodderstedt (OpenID Foundation/SPRIN-D)
• Joseph Heenan (Authlete)
• Tim Cappalli (Okta)
• Derek Hanson (Yubico)
• Hicham Lozi (Apple)
• Nick Doty (CDT)
• Oliver Terbu (MATTR)

Notes

Administrivia

Tim wants to know if people are planning to come to IIW Tim scheduling an extended call to discuss the format/protocol parameter and related registry

Intros

None

Updates from Blink / WebKit incubation

None

Discussion: Limit access to the API based on known allow listed origins #59

Tim: Kyle raised, should there be a domain allowlist for who can request PII

Tim: Will have this discussion on the next call too

Tim: Good discussion in the issue

Tim: There are other primitives that use allowlist

Tim: let’s open it up

Rick: Kick it off by asking a discussion: is this about the browser API or for other mechanisms too? I’m thinking about the ways these things get around our protections

Nick: Think it should apply generally. Browser API is the best place to provide mechanisms for the origin to communicate to the user. Allowlist could be registration/precommit of the purpose so that data protection authorities being driven. Probably worse option could be user-controlled.

Rick: What do you mean about the browser API being a good place to start. Current scope will be custom-schemes only, and we are coming in after.

John Bradley: Custom schemes are the requirement under the technical regulations

Nick Doty: Technical regulations are not complete

John: large scale pilots are underway already that use custom schemes. QWACs, OpenID metadata are different ways for this to go. Entity Categories are subsets of the credential that can provide clear subsets. Issuers should issue to wallets that only reveal to verifiers

Nick: The browser is a place to do some of these things, because it’s one of the interfaces between origin and user

Torsten: We should not rely on the browser: the wallet is the UA in the regulator. Wallets are not only accessed through the browser. The way an RP is identified is not by the web origin. The mechanism is not decided yet. Assume there is something on top of the web layer. There should be an API designed such that it is not reliant on an origin.

Lee Campbell: +1 to Torsten. A platform level allowlist would not scale here. Example. Platforms can help with cases of abuse, i.e. safe browsing

Martijn: We need to be mindful of international use. Does the relying party not have a direct relationship with the issuer. Consider international issuer

Ben: One challenge is determining legitimate use from a safe browsing perspective. E.g. what if they aren’t doing the appropriate request. Lots of gray areas

Ben: protocol as control point. In instances where there is an issuing authority having some degree of control over who is able to verify, that is something that could be leveraged. Authenticity from the verifier

John: Three party model is much more complicated of a trust relationship. Need metadata. RPs need to work with identity from around the world. Need a trust-mark in the metadata. Putting this in the browser API will make us insane. Put it up a layer.

Nick Doty: Understand hesitation about the complexity. Needs to be addressed at the browser level because of developer experience. Webdevs will have a hard time with failures from miscellaneous wallets. Wallet trust seems implicit. I don’t trust all wallets personally.

Rick: Do we need an additional layer of what wallets can handle which requests. What stops wallet X from claiming they handle EUDI wallets? Are there technical mechanisms that prevent this?

Lee: Issuers verify this. Wallet X only can get a credential

Rick: Can the wallet just fake it?

Lee: Yeah, to some extent. But will fail on the RP side. Malicious holding of requests. App store policy violation. Cryptographic enforcement is something we’ve thought of, but didn’t do yet due to complexity and lack of demand.

Torsten: Trust management infrastructure exists. Wallet provider certification surfaces in a cryptographic manner for EUDI

Lee: RE: Nick, we do care about developer experience.Too many wallets. Need to know the issuer. Developer needs to know where to look to figure out how to get it to work

Ben: the wallet is representing the user here, however the browser is the user agent in the context of the web. Where is the line between wallet’s responsibility and the user agent. Don’t know which type of wallet you’re trying to get the request to, or whether your privacy is going to be requested. Tough position as a browser; need to offer users protection as much as possible.

Tim: Layering conversation is a challenge because we have two user agents, perhaps for the first time? RE: web plaftorm and native apps- we kind of already have this with FIDO. App platforms need to make decisions clear. RE: Torsten, that trust infrastructure you mentioned- is it evaluated during issuance or validation?

Torsten: yes, however we might do it during presentation. Increase technical complexity significantly without benefit, but this is a political process

John: More dynamic, issuer may have a policy with the wallet saying, e.g. you can only make presentment to these RPs with this trustmark. The only thing that makes sense globally is a hierarchy of trustmarks. What do we do with issuers that don’t have privacy guarantees?

Ben: To what degree do we trust the issuer, specifically to protect the user’s privacy? In the EU, there are regulations, but do we want to have a universal policy that applies to all issuers? Treating two issuers differently, making a judgement call

Rick: Criteria on requests? Reliable identify EUDI wallets, sure! Risk scoring of requests.

Ben: Looking at the request itself. Ties nicely into John’s comment about trust marks instead of using issuers themselves

Kristina: maybe we should be discussing if we want to treat all credential types the same or differently? What about non-high-assurance credentials (not gov id), e.g. tickets, education credentials, or library cards. Do we need a non-exhaustive list of credential types? Protections could be different based on DL vs library card.

Lee: Southwest card example- agreed! Global policies are hard. Banking app would need a ton of hoops to show something to its own site. User consent covers a lot. We are setting the bar really high. Users are making educated choices about where they log in with federation and about data exchange. We want to allow these things to more, not create a fragmented system

John: We will see a proliferation of credential types. EU social security card, student IDs, research grid access for telescopes or CERN. Even coming up with the presentment of two credentials at once. This will spread. Airlines, credit cards, yada. Browsers will have a hard time keeping up with all of this, and if we are working from an allowlist they will go around it and we will be back to square 1

Hicham: ISO registry for mDoc

Nick: Detail on registry? Kristina’s idea of a registry is interesting. Adding privacy info to that registry is good. Consent is insufficient. Especially for irrevocable gov ids. Every site demands full ID to use. Is that really consent?

Kristina: Is that a closed or open doctype registry in ISO?

Hicham: Will give info on registry next call

Lee: Summing up: reluctance to build a global allowlist, but there is a problem here. How do we ensure wallets are acting in good faith.

Tim: I will summarize the notes to spearhead the conversation next week.

Lee: Does anyone think a global allowlist will work?

Tim: this is Kyle’s issue, let’s wait until next week.

Nick: There is something in between allowlist and trustmark that we need.

Lee: well-known per RP that says what properties are needed?

Lee: Do we think the platform takes some control from the issuer?

Tim: Probably- tracking!

John: FedCM is a thing to preserve it

Lee: Maybe there are formats that are not privacy preserving enough

Tim: Not a binary answer. FedCM looking to get rid of it long-term

John: pairwise non-identifiable credentials are good, but we don’t know the semantics of the VCs

Rick: Disagree with Tim: Chrome doesn’t want to eliminate global identities from the web, but want the easy path being directed. User consent is the line that we allow the user to break out to a global ID

IIW Planned Attendance List

April, Mountain View: https://internetidentityworkshop.com/

• Lee Campbell
• Sam Goto
• Tim Cappalli
• Oliver Terbu
• Joseph Heenan
• Wendy Seltzer
• Rick Byers
• Torsten Lodderstedt
• Heather Flanagan