Skip to content

2024 01 24 Meeting Notes

Jump to bottom
Tim Cappalli edited this page Jan 25, 2024 · 2 revisions

2024-01-24 (B Call)

Organizer: Tim Cappalli

Scribe: Lee Campbell

Agenda

Attendees

  • Benjamin VanderSloot (Mozilla)
  • Lee Campbell (Google/Android)
  • Rick Byers (Google Chrome)
  • Kyle Den Hartog (Brave)
  • Orie Steele (Transmute)
  • Mike Jones (independent)
  • David Waite (Ping Identity)
  • Marcos Caceres (Apple)
  • Joseph Heenan (Authlete)

Notes

Intros

Kate from Android DevRel working on Android’s Identity APIs

Updates

Chrome: Sam is updating the chrome implementation to match the current proposal in the github. Will be a breaking change at some point. Only one implementation will go to origin trial

Marcos: Put a patch up for WebKit for the IDL. Put together initial draft of the spec

Rick: Browsers don’t need to be total lockstep at this point in time as we’re iterating on the spec.

DigitalCredential PR

Marcos: New PR up with the latest proposal and a PR for an initial draft of the spec

Marcos: First stab at defining the model and terminology and scope.

Marcos: Slowly building up the WebIDL for the various types that we need.

Marcos: Need to specify the key param. It's still undefined at the moment.

Marcos: Lots deliberately left undefined so the group can figure out the details

Marcos: Looking for collaborators to work on this spec.

Marcos: Lots of open questions, e.g does it work in iframes, do we need a permission policy

Marcos: Initial Register for request protocols is in the spec, intended just to be a starting point to drive consensus and debate.

Sam: Really appreciate the PR! Lets try merge and baseline and build on it with smaller PRs

Rick: Happy to merge PRs with open issues as long as the issues are tracked

Marcos: Lets try to build consensus in the spec.

Orie: Lets try not to fill the spec with red issue markers as it will have a lot of eyes on it.

Marcos: Anyone want to co-edit?

Sam: Happy to be co-editor

Rick: Happy to as well. Chrome will figure out who it will be

Ben: Interested but needs to confirm bandwidth

Marcos: What are the policies for merging PRs?

Repo name: Should we rename from IdentityCredential to DigitialCredential?

Issue #35

Tobias: Why is this conflicting with FedCM and why do we need a new name? Should we take the opportunity to have a single term

Sam: Chrome already ships the IdentityCredential interface for FedCM already. There is a big intersection, its all federated identity at the end of the day. We did try to merge them, but feedback from Safari was that it was too early to try to bring these things together. Pragmatic to split them now, but likely we will duplicate work.

Sam: So we have to change name if we want to avoid that conflict.

Ben: FedCM is designed for sign-in, where using something like an mdoc to login is much more controversial.

Tobias: Need to be aware of the developer fragmentation.

John: Can I make one request that could return either FedCM creds or DigitalCreds? They are fundamentally the same. Neither are strictly identity either.

Kyle: Thinks of it as an extension of FedCM at a technical level, but political differences to keep them seperate. Could combine them in the future but combining this extension spec into the main specification.

Sam: OpenID also split things between OpenIDConnect and OpenID4VP.

John: Organisted this way for the purpose of managing calls and logistics. But its not that we believe they are fundamentally different.

Sam: Share the intuition that users don’t want to see multiple prompts. Would want to see results in a single prompt. Maybe not perfectly architecturally correct but the best starting point

John: EIDs don’t have to be the three party model. Lots of gov IDs using two party OpenIDConnect

Rick: Found a compromise where this lives in the CredMan framework. Do we need to change the method name too if we change the name to DigitalCredentials

Sam: When you subclass Credential it assumes you can request them in conjunction with the other credentials through .get(). But we’re not fully integrated into CredentialManager yet

Marcos: Missing the other management APIs today (e.g create)

Lee: Will likely have to support issuance in the future.

Tobias: It does fit quite well even if we don’t implement every management function. Get alone fits the model.

Kyle: Combining these things too much might not match the user and developer expectation. Are we combining too many things into a single flow, which

Lee: In terms of should they appear in the same thing: in android native, we do think they'll have to be presented in the same flow at the same time in the same UI and same get flow. Eg. want to verify age and will take driver's license or OIDC assertion. We don't have the problems with FedCM, have a clean slate. But one data point for how Android will likely do it.

Ben: Expect that requestIdentity would return something abstract that could be a DigitalCredential or a FedCM credential etc.

John: FedCM maybe good enough for some authn use-cases, but FedCM on its own might not suffice on its own for all usecaes.

Marcos: So can I rename the repo? :)

Sam: Happy to rename repo, but have another discussion about kind of UX. Believe it should be stronger integration with CM

Tobias: Need to revisit other API names - IdentityCredentialProvider.

RESOLUTION: rename repo, but everything else still an open question

AOB

Ben: Was asked what Mozilla thought of moving the request protocol conversation to OpenID. This might be tricky currently as there is no involvement today with OpenID Foundation.

Kyle: How do we decouple key management from this. e.g hardware backed keys in webcrypto and re-using that primitive. Could be useful to solve fraud

John: Working on a web wallet project. Proposals in FIDO to webauthn to store keys for a web wallet.

Clone this wiki locally