Consider incorporating into Credential Management API

[bslassey]

There seems to be a lot of overlap between this and the Credential Management API. It would be interesting to explore how this could be mapped into that API as another credential type.

[hlozi]

Looking at the credential management API it is focusing on sign-in credentials and authentication actions. I am concerned that integrating the mobile-document-request-api into it would give the wrong impression that mobile-document-request-api is a sign-in credential API.
The proposed mobile-document-request-api is not meant to be a sign-in API, it is more about the presentment of a Mobile identity document existing on the device.

[samuelgoto]

Looking at the credential management API it is focusing on sign-in credentials and authentication actions.

I agree that the current credentials (namely, WebAuthn, Passwords, WebOTP and FedCM) are authentication related credentials, I still think it is worth bundling this API into the credential manager, because it seems likely to me that you'd want to get mdocs in combination with the other credential types (as well as future credential types, say, verifiable credentials).

That is, I think it is important that we design the API to allow a user agent to construct UX that allows a user to pick mdocs in conjunction with other identity attribute types (e.g. maybe the website wants the user's email and age, and while age may come from mdocs, email could also come from, say, federation).

Identification is often followed by authentication, and often bundled (e.g. I often need to give my name/email to websites in addition to my username/password).

I am concerned that integrating the mobile-document-request-api into it would give the wrong impression that mobile-document-request-api is a sign-in credential API.
The proposed mobile-document-request-api is not meant to be a sign-in API, it is more about the presentment of a Mobile identity document existing on the device.

Yeah, I agree that that's a valid concern, but I think that perception is more easily addressable compared to designing the API such that the user agent is unable to combine mdocs with other data sources in the credential manager.

[othermaciej]

I don't think it's a good idea to mix real-world identity documents with login credentials. We don't want to encourage use of mdocs for login flows. And the notion that both are a kind of "credential" is at too high a level of abstraction to be a useful guide to API design. As a digital cryptographically protected representation of a real-world document, these things are more akin to PaymentRequest payment instruments than to login credentials.

[kdenhartog]

We don't want to encourage use of mdocs for login flows

As a digital cryptographically protected representation of a real-world document, these things are more akin to PaymentRequest payment instruments than to login credentials.

I agree with both of these statement, yet I'm not convinced that moving them to some other API actually solves this problem. In fact, in my experience working with verifiable credentials (VCs) and hearing about every use case that people had for VCs most use cases kept falling into the pattern of being used as some form of attribute based access control credentials to convey an identity. I highly doubt that moving these to some different API is going to deviate web developers from using them in this way either.

For example, if we look at how all of these physical credentials get used in digital interactions today they are almost always focused on registration or recovery flows because the UX to verify these physical credentials is not very good, but still trustworthy enough to push the user in that direction on limited circumstances.

Assuming the model that's been popularized by the Issuer-Holder-Verifier architecture takes hold the only thing that's actually going to limit these from becoming credentials used as frequently as login credentials is recreating some form of UX burden in my opinion. Moving these APIs might give us greater control to restrict the developer availability to these APIs such as @samuelgoto point about limiting which credentials can be defined, but AFAIK there's nothing specific about the credential management API implementations that make it so that this couldn't be handled there either. In Chromium's implementation it appears like it would be easier to handle it there rather than via a separate service although it still can be done as a separate service. However, I've not looked at Webkit or Firefox's implementation to see if that would hold true for them as well.

[RByers]

We don't want to encourage use of mdocs for login flows

I'd go further and say we should probably discourage use of mdocs for login flows. They may be appropriate in some signup flows (eg. signup for government or financial service), but should then exchanged for a lighter weight and safer credential like a passkey for future logins. I think the last thing most of us want is to be training users to just tap that "login with my drivers license" button on every site they visit that wants to better target ads to them!

Assuming the model that's been popularized by the Issuer-Holder-Verifier architecture takes hold the only thing that's actually going to limit these from becoming credentials used as frequently as login credentials is recreating some form of UX burden in my opinion.

100% agree with this. My position (in helping to lead identity work in Chrome) is that we need to have a pretty strict hierarchy of friction in our authentication and identity UX where friction increases with the privacy risk. So we will work to make passkeys quite low friction, age verification moderate friction, and full government-backed ID presentation higher friction than that.

To me the compelling argument for putting this into the CM API is that there's almost certainly going to be multiple identity formats in wide use. It already seems as both mdocs and W3C VCs have momentum for government ID. Scenarios like proving your university affiliation will want to draw on a variety of sources, including leveraging the existing OAuth IDP ecosystem. The more we can give flexibility to sites to express what sources they're willing to accept, the better chance we have of being able to design UI flows which can evolve to best align with user interests. The alternative seems like a continuation of the world where a site presents several options to users (strictly using it's own idea of preference to rank them) and users need to make a choice before they have the full context to predict the implications of that choice (like which of their identity sources are actually available under each choice, or which pose a greater risk to their privacy).

@samuelgoto, @agl, and others have been noodling over this and the great feedback from @othermaciej in #5 and we have come up with a draft explainer for an IdentityCredential framework on which this could build. Thoughts?