Converged Use Cases for the Credential Management API

[timcappalli]

Session description

The Credential Management API has rapidly evolved into a critical component of identity on the web. From enabling seamless passkey experiences via WebAuthn to integrating federated identity flows through FedCM, facilitating SMS OTPs with WebOTP, and now facilitating the exchange of verifiable digital credentials via the Digital Credentials API, its scope continues to expand. This proliferation of capabilities sparks a critical discussion: how can these individual strengths be synergized for richer, more secure, and user-friendly identity experiences?

This session aims to explore three key scenarios: first, the concept of multi-type credential for sign-in requests, for example allowing a single API call to solicit a passkey, a password or a federated identity, second, a multi-type credential for identity attributes, for example allowing a single API call to solicit either a federated assertion or a digital credential based on the application's needs; and third, the potential for a method that combines identity claim acquisition (e.g., name and verified email via federation) with simultaneous passkey creation, streamlining initial sign-up and subsequent passwordless authentication.

Session goal

Ideation and requirements gathering

Additional session chairs (Optional)

@samuelgoto

Who can attend

Anyone may attend (Default)

Instructions for meeting planners (Optional)

No response

IRC channel (Optional)

#credman-convergence

Agenda for the meeting.

No response

Scheduling conflicts to avoid (For meeting planners only)

No response

Links to calendar

• Wednesday, 16:15 - 17:15

Meeting materials

• Minutes

[tpac-breakout-bot]

Thank you for proposing a session!

You may update the session description as needed and at any time before the meeting, but please keep in mind that tooling relies on issue formatting: follow the instructions and leave all headings and other formatting intact in particular.

Bots and W3C TPAC breakouts organizers may update the description at any time, to fix formatting issues or add links and other relevant information. Please do not revert these changes. Feel free to use comments to raise questions.

Do not expect formal approval; W3C TPAC breakouts organizers endeavor to schedule all proposed sessions that are in scope for a breakout. Actual scheduling should take place shortly before the meeting.

[samuelgoto]

We recently published a couple of proposals/explainers that might be relevant to this discussion, so I figured it would be useful to share them here in case you haven't run into them yet and could use a pre-read.

first, the concept of multi-type credential for sign-in requests, for example allowing a single API call to solicit a passkey, a password or a federated identity

w3ctag/design-reviews#1092

The immediate mediation mode allows the browser to offer a credential choose that unifies passwords, passkeys and federation for returning users.

and third, the potential for a method that combines identity claim acquisition (e.g., name and verified email via federation) with simultaneous passkey creation, streamlining initial sign-up and subsequent passwordless authentication.

https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-requestUserInfo

The WebAuthn Request User Info API allows developers to get claims (self declared or verified) as well as a Passkey at the same time.

second, a multi-type credential for identity attributes, for example allowing a single API call to solicit either a federated assertion or a digital credential based on the application's needs

This is the only one that I don't think Chrome is actively working on ... I think the closest we got for this is reconciling them in autofill, with something like a conditional mediation for FedCM and DC, but it is unclear if this is going to be necessary/useful:

w3c-fedid/FedCM#694

[timcappalli]

Session notes:

Scribe: Manu Sporny

Tim: let's kick off – thanks for coming – session on credential management api and how things hang off of it. I have a few slides to set the stage a bit. Hoping for some good discussion.

Tim: multitype sign in requests, Multitype identity attribute requests - need identity data from different sources – how to do those through one request, converged account creation requests. Account creation APi, results in something like passkey.

Tim: refresher of credential management api – defines navigator.credentials. Types – public key, password, identity, digital, otp credential typesl. This is the beauty of credman, can be extended from other specs. A lot of things inherit from credman.

Tim: First example, multiitype sign in requests – how to say "I accept any of these type of credentials – mockup can be hcallenging. In ideal scenario, user only has one,.. Developer can make one request, credential manager holds credential, person makes selection. This allows people to NOT flalback to text field if it can be used via credential manager API. If we can optimize experience, huge developer improvement. Leverage conditional mediation, and immediate mediation (seamless fallback). Only show dialog if actionable to user (Immediate mediation) – if you call WebAuthn, greeted w/ blocking screen – problematic, complained about a lot. If you have a passkey use it, allow seamlessly fallback to legacy form. That's a gab.

Tim: Multiple identity claims – VDCs or ID Tokens are similar, but assertions that carry identity claims, signed by issuer you can trust – where you get them, where they are stored, that's where they diverge. Verified phone number could come from a variety of sources. Age verification, age token doesn't have to come from a government id and – doesn't have to be verifiable digital credential. Proof of employment, workforce example – hard to set up between two organizations – my company uses Google workspace, others use Microsoft… securely sharing documents, create account for another company – "Share with Verified Authorized Organiztaion". Developer could say, accept both sources/token types, let user pick really attractive.

Tim: Converged account creation request – create account, source information dynamically from where user chooses – get call from fedCM, get name and email, get verified phone number, there are benefits of not round-tripping user to – users don't like to type things in, autofill only gets you so far. Nina working on for webauthn, autofill + verified email. Create a passkey and away you go. GET and CREATE aren't allowed at same time…

Tim: Ongoing / existing work credman, webauthn, webauthn: immediate mediation, Chrome: passwordCredential + PublicKeyCredential, Chrome: Email Verification Protocol. People want to do this work.

Tim: Some question to drive: Are there sites/RPs interested? Are there additional combos/scenarios that are missed? Developer ergonomics: Should be new alias / use case driven methods – should there be new aliases, new getAndCreate function?

Arim: In terms of developer ergonomics, challenges with flows, chrome UI isn't great intersects badly with sites that create same UI – we want premium experience – having same sign in flows as pornhub is not great. In term of developer ergonomics, having these be displayed differently would be of high value.

SamGoto: Shopify brought it up – pepsi had closest to mediated UI – common request.

PhilArcher: Different set of use cases, authenticating product i'm trying to ship to system. Want to use credentials – sell stuff on online marketplace, want to prove barcode came from GS1 to do that. In international trade, certificates of origin, invoices, those are our use cases, not about individual, about thing I'm talking about.

Tim: is this a bearer code? Signed?

PhilArcher: Yes. I'd need to provide credentials about other than me.

Tim: So interrupt driven flow?

PhilA: Something like that, yes?

Rick: No way to have ederated credential

Sam: Passkey creation API – get passkey and user name and user email address and cryptgraphically verified email address. First instance where we return to user multiple things.

Nina: Credential manager APi is hat you can ask is one of these OR one of that. If you have a map of things, ou can only hoose ands or ors, unless you have another layer? If you look at account creation pi, it's nested, also request user info – nonce more property of each credential type, maybe property of DC API and not at high level of credman

Tim: Better to have get/create and let client reason –

Sam: Hard to think of this ahead of time, I believe that architectural choice so far that Nina team has arrived at is appropriate one. How would we create a passkey creation API – seemed a natural way to extend public credential type – vs having query language in higher level API. Constrain query language to use case specific increase use cases to purpose specific

Nina: Don't want to construct a query language. The way of constructing the object is create and you pass public key credential dictionary has all the options that you have in webauthn request. Cryptographic parameters for email creation, then browser renders a UI, because we're hanging attributes from pu blic key credential, shape of API is not so generic.. Sie gets back public key credential from webauthn, userinfo hing has added stuff, tacked on response, I think this is reasonable?

Tim: Mapping back into inputs to webauthn request.

Sam: This turns into use case specific quer language, where DAQL turns into use case agnostic query language.

Tim: They want an account – passkey has identifier – there's nuance here – do we want to define semantics at other interfaces.

Sam: Some of this was inspired by Apple for native apps – how would you design an API –

Apple: On this topic when credential creation request is made, creating account, deleted an account, user agent and operating system have every little context to work with – in our API, it is explicitly framed as an account creation API – couldn't think of any other thing – do nice things in UX by being specific. Might want to look into what Native API – fact that UX creates an account and account has passkey, great – talked to rP if they don't need any extra bits of information so they get UX for creating an account instead of saving a passkey.

Sam: when I looked at this, it was very passkey specific

Apple: An account will be created –

Tim: This is user facing UX

Sam: When I look at this, I got – this sound slike valid pubic key credential call – as opposed a credential manager request – public key credential, self filled name, etc.

Tim: It's semantically clear

Sam: What's the get here?

Sam: What Apple has done before in native API, it's autofill data – self asserted credential.

Tim: How do you layer in different data from different sources?

Nina: I don't think it's a terrible idea, have a use cae specific way to do that. General query language – already have to think abou nonsensical combinations – digital cedntial and OTP – how do you communicate this to user? Doing this doesn't preclude us from doing other stuff later… more case -

Sam: Nina and I were using this like a test – if developer wants to create account, user assertion that user is voer 18, come in separate screen .

Apple: That was a thought we through through w/ Apple, age versioncation was too much in a single screen.

Tim: The data that makes up traditional account could come from a different source.

Sam: What will we tell user – what's title of the screen say?

Apple: What is the intent of this question – what does it mean to have something federated in here – passkey is the way its done. Don't know what it means to put something federated in here.

Tim: It means you don't have to do a bunch of email verification roundtrips.

Sam: There is a distinction between sign in with Google vs. cryptographic verification. What a user expects out of this, when you select an email address, no one else finds out about this?

Arim: How does that work? If flow is popping up a UI like this, my expectation i Apple is aware that I am sending my email to shiny

Martin: This isn't going to Apple's servers in this case.

Arim: Apple the company is knowing that the email is connected to this company. The question of autofill is different from popping up a UI like this. Device-isolated thing. If a system UI pops up, then I assume that system is aware of, then who I purchased system from undrstands where this comes from – i'd prefer this is an autofill.

Nick: You are gooing to see flows where password is in flow – this passkey is going to be stored in onepassword – where using UI is the medium for ti.

Dan: When you're saying "Apple knows", you're saying "Apple's software knows" – if government subpoena's information –

Apple: We should move on. Arguing about what different people understand is an anecdotal – we're trying to design API that will deliver – everyone is right, let's move on and go back to API discussion.

Marcos: Is it always Get / Create?

Tim: Yes

Marcos: Always in that order

Nina: We already have this API – sign in with VC get passkey for free –

Sam: You could have an autogranted passkey – two FedCM / DC API cal can't au

Tim: Problem with conditional create might leave user w/o credential – this has to explicitly return passkey or not

Nina: What if world is multiIDP – eg. you're on chrome use Meta to verify your identity – combined dialog, verifying identity with meta, but password shows up on Google Chrome/Windows Hello. Being optional, gives us more flexibility – if you really want passkey, two dialogs – if user is happy w/ storing passkey in password manager, user has cred

Tim: Assumption is user has credential manager

Nina: Sometimes people have two available – we're going to be stuck with this forever.

Tim: Users choose a credential manager, we can change this.

Brendan: In some cases, that's out of the control of the user because they have an employee relationship w/ corporation.

Arim: Almost every browser has password manager, and we've told peopl they have multiple password managers – maybe they don't use one in browser, but there are two of them on the machine.

Nick: We are a tenant on another platform, the other credential managers are trying to resolve that at the platform layer – people want to just use one, the one that they chose – it's reasonable, we can figure out how to funnel users into flow they want to perceive. IOs platform UI – user puts passkey where they want it to go. What does this ook like in an ideal state to get credentials into ONe spot and not have to use multiple credential managers.

Tim: We are taking something that is self-contained and splitting it – you don't have to do anything regardless of where it is stored – consumer federation is the worst thing for the web – one click button, but creating a privacy preserving passkey

Sam: What Nina i suggesting can be as efficient for account creation, Nina's proposal provides a passkey, a name, and ability to provide cryptographic verified email address. As far as UX goes, user accepts prompt just shown for apple platforms, arrived at same end state as user provided for sign in w/ apple/google.

Tim: Could take output for FedCM and do ame thing
Nina: Not if email provider is not an identity provider, and not if integration requires – this is a NASCAR problem

Tim: In both cases, someone has to do work, o

Nina: only implement – same logic for everyone

Tim: same logic for everyone

Apple: At Apple, with shipping this API and native conversion of this, we concluded that it had value to people w/o email address being verified, we thought it was hard, how is it implement, how long will it take – might want to design where email is proved, don't let one block the other.

Nina: I'm partial to Sam's proposal, but if we should do something else – we can put other stuff in he object.

Apple: We don't want people to think email is a blocker.

Sam: It addresses Tim's point about it being as efficient as federation. Generally for

OnePasword: You have to do consent for claims, consent for wha is being sent – within the same UI, this is going to be shared, do you consent.

Sam: FedCM UI is

Arim: Do we need to require thing other than the passkey – allow people to sign in w/o email, and then we ask them for email because all features are email based and user usually provides it – we are a service does email stuff, we need you to

Nina: Way it works – "I want passkey, one of these identifier" – "email is onl I accept" – or "email or phone" – set of attributes… name, phone, you are in control of RP of what is asked of user. You can't ask for multiple identifiers at the same time. You can't say give me email and phone

Arim: Passkey is always required as a return.

Sam: No API that provides just emai and phone.

Tim: We got that sites are interested in these concepts. We are not in favor of GET and CREATE, we want Nina's proposal.

: Generaleized get and create is too complex – let's start at simple place Apple st arted – phone and government ID might be common cases in the future.

Apple: If we build a more generalized one, we could rewrite in more genralized on in future.

OnePassword: If we go with that, websites will do a Get first and then a create and two dialogs –

Tim: This doesn't solve for those cases.

: We can

Tim: I feel weird about account creation api hanging off of public key credential. Feels strange

Sam: There is a modal dialog where we create account – passkey creation is anchored on passkeys, it's not a general purpose API.

Apple: We don't have GET / CReATE – we have factory that creates requests. With Tim that developer picking this up should know from the API name.

Sam: Conflicts a bit with credman api that chrome shows account on website with federated identity provider.

Tim: The result of that doesn't mean you get to create an account

Sam: that's how API is being used.

OnePassword: We have precedent that adds things – take it out of publicKey have metadata during create? That should be on the table

Martin:People create passkeys, we need to name it what it does – creates a passkey. It's create a passkey with conditions.

Tim: There is aso creating passkey, taking parameter from server

onePassword: Setting additional account creation data which is fundamentally different.

Tim: Where do you get user handle from?

Nina: That comes from the server.

OnePassword: Where do you want to discuss this?

Tim: We don't have a good place to discuss this.