Clearly separate presentation of issuer-signed Credentials from User Authentication Event

[Sakurann]

I do not think it is a good idea to use identity credentials for authentication. and I worry that allowing to combine federated and mdoc or vc in the same API like shown in the Reconciliation section fosters exactly that.

In Federation, it is the Issuer (IdP) who authenticates the user (proof of authentication is ID Token, SAML assertion, etc.). For example in the ID Token, iss and sub claims are mandatory and are used to express that iss authenticated the end-user identifier as sub. ID Token does have data about the end-user, but it is only meaningful because it is combined with an authentication proof: "Issuer authenticated the user and is providing some values relying party can use"

Identity Credentials (placeholder term for both mdocs and VCs) are different. There, user authentication is optional and if performed, it is the Wallet (not the credential issuer) that authenticates the user when presenting issuer-signed credentials. So a user identifier assigned by the issuer does not have any meaning for the verifier as it does not bound to authentication - the sub claim in the issuer-signed credential is optional (in fact mdocs do not have an equivalent to a sub claim in the ID Token; in W3C VCs it is used to discover the keys to validate the signature by the user's key). the value of the identity credential is orthogonal to user authentication, "Wallet is proving that a certain issuer-signed credential has not been tampered with and is being presented by a legitimate user". with identity credential presentation, there is a need for a separate proof of authentication - can be Passkey, Self-Issued ID Token, etc.

maybe it is a good idea to have a same API for federation and mdoc/vc, but allowing to combine federation and mdoc/vc in one API call is concerning.

Hope this makes some sense..

[RByers]

Thank you Kristina and sorry for my delay in responding. @hober has been telling us WebKit feels the same way and filed #16. The specific use cases we had in mind for combining federation and mdoc/vc is age and affiliation verification. Today federation is used broadly to prove membership in a group (eg. school for journal access), but we expect this to become common with VC/mdoc too. If we don't allow both to occur in the same selector UI we worry it'll be harder to transition to the more private holder pattern given the user friction involved in asking users to make a technology choice up front that they may not understand. WDYT, do you think it's plausible that allowing some federated use cases to be combined with wallet use cases could be desirable?

We (Chrome) are thinking of the requirements as:

• Support a single credential picker for wallet and federation credentials (eg. for affiliation verification and perhaps age verification)
• DON'T support a single picket for authentication (eg. passwords/passkeys) and wallet credentials
• Support a single credential picker for passwords / passkeys and federation (for better or worse, using federation to sign in to websites is very common today - users shouldn't have to remember if they logged in last time with their social account or a passkey)
• Make the identification / authentication separation clear to developers

Chatting with @hober and @nsatragno (CM editor), we think the best way to meet these requirements is something like the following:

• Add a getIdentity method to CredentialsContainer which is strictly limited to getting IdentityCredentials, but otherwise is the same as get (can probably share almost all the same spec text, just in a different mode)
• FedCM can still extend get to allow FedCM IdentityCredentials as a bit of an edge case - where identity is being used for authentication purposes
• We can otherwise prohibit IdentityCredential from being returned from get

Thoughts? /cc @samuelgoto

[samuelgoto]

Add a getIdentity method to CredentialsContainer which is strictly limited to getting IdentityCredentials, but otherwise is the same as get (can probably share almost all the same spec text, just in a different mode)

I'm not terribly excited about navigato.credentials.getIdentity() in the CredentialsContainer, but I am empathetic to the problem described: decoupling (a) mdocs/vcs from FedCM and (b) identity verification from authentication has a lot of good properties.

There were a couple of proposals that I heard in the past that I think would accomplish that best:

1. Expose a navigator.identity.get() -- in a way equivalent to navigator.credentials.getIdentity() and/or
2. Introduce a new Credential Management credential type, say, a VerifiableCredential (or a WalletCredential), so that it can be requested independently of FedCM (and other Auth-like types, like the PublicKeyCredential). We'd likely have to pick a different credential type other than IdentityCredential, unless we wanted to make backwards incompatible changes to FedCM.

I believe these two options meet the goals you described. (2) is more incremental and (1) is a bit more abrupt, but still manageable.

Last time we chatted with @hober, I got the sense that (1) would work for Safari (i.e. they weren't married to getIdentity() per se -- they just wanted to make a separation between the Credential Manager API and leave that for Authentication). I don't completely buy that going with (2) would make mdocs/vc authy-like because the Credential Manager API is designed such that you can fail the request if you get an invalid combination (e.g. today, if you request a WebAuthn, a WebOTP and FedCM assertion at the same time you'd get an error -- and that's ok). Anyway, either (1) or (2) would be reasonable starting points that I think wouldn't corner us from what we'd like to accomplish.

I wrote some of this in the alternatives considered section, but I think I'll take a pass at writing down the alternative proposals on their own so that we can compare and contrast, given how much this has come up in the past.

I think navigator.credentials.getIdentity() isn't ideal because, as of right now in Chrome, that spells precisely how you'd get the FedCM IdentityCredential: navigator.credentials.get({identity: ...}) and it would be confusing to have both of these things (in an inconsistent way).

[bvandersloot-mozilla]

I agree that separating out Identity from Login mechanisms is helpful to do here. Creating a parallel CredentialsContainer on navigator.identities seems like the more straightforward way to do this. Then the user has two independent places where Credentials go that accept different subclasses of Credential.

FedCM is weird, and I'm not sure how I feel about it existing in both navigator.credentials and navigator.identities. I suppose it may reflect reality best though. How do we hit Chrome's last (tentative) requirement, to "Make the identification / authentication separation clear to developers", in that case?

[samuelgoto]

but I think I'll take a pass at writing down the alternative proposals on their own so that we can compare and contrast, given how much this has come up in the past.

I took a pass at this and added a couple more valid alternatives here that we discussed in the past:

• navigator.idenity.get() and
• Digital Credential

Creating a parallel CredentialsContainer on navigator.identities seems like the more straightforward way to do this. Then the user has two independent places where Credentials go that accept different subclasses of Credential.

Yeah, that would be a reasonable way to go about things.

FedCM is weird, and I'm not sure how I feel about it existing in both navigator.credentials and navigator.identities. I suppose it may reflect reality best though.

Yeah, I think that's what I'm arriving at too: federation is weird in that sense, in that it is used both for logging-in as well as for identity verification. That is, FedCM existing in both places would be more work for browser vendors, but seems like a justifiable design choice.

[RByers]

Chatting more with @samuelgoto about this, we see how FedCM is really complicating the debate here. In the interest of helping us all converge to a v1 we're all happy with, we agreed to fork off the FedCM question as future work (#23) and not block on it for now.

[marcoscaceres]

Ok, so I believe we did settle on .requestIdentity() for now as the means on making the distinction between authentication and identity requests.

Can we close this issue for now?

[timcappalli]

Cleaning up issues. This is an old discussion. The group landed on navigator.credentials.get|create with the digital type.