Update suggested API.

[agl]

This change updates the proposed API to use IdentityCredential instead.

[bslassey]

I have since been told there is an older closed PR and an open issue which give some of the motivation, @othermaciej I believe that PR #3 and issue #2 are the ones that were referenced.

[agl]

Thank you for the feedback!

This change was intended to be a quick aid to some ongoing discussions, but it has been hanging around longer than anticipated, so I apologize that the context was missing. I’ll try to fill it in:  

We also want to see a clear separation between authentication and identity. While we cannot stop identity mechanisms from being used for authentication, we want that to be cutting against the grain. We started by putting this functionality into a new navigator.identity namespace, but ultimately decided that navigator.credentials was a better fit because of federation.

We would like federation to evolve into an identity mechanism, and for authentication needs to be served by passkeys. So we envision that a site would create an account by creating a passkey and then optionally attach identity attributes to that account, like an email address, by using federation. That's why FedCM currently uses navigator.credentials.get({identity: …}). But then if we put real-world identity functions in a navigator.identity namespace, we would have identity appearing in two different places. We felt that undermined the benefits of separation.

Federation is used for both authentication and identity today. We can't separate that in the short-term. And we do want to be able to support authentication requests which accept either a password, or passkey, or federated sign-in. (There are numerous examples of sites that have such a UI right now, although perhaps without the passkey option yet.)

So that's why we put the API into navigator.credentials.  

As for tying it with FedCM: as mentioned, we would like to move federation towards being an identity mechanism and so we want to support sites being able to request identity attributes using either mDLs or federation. If mDLs are only ever used for mobile driver's licenses, that doesn't make a lot of sense. But we expect that the mDL data model will be inevitably used for other things too. For example, proving an academic affiliation is often implemented via a federation-like mechanism today (SAML, specifically), but it seems reasonable that it could be an mdoc too (e.g. University Certificates). (And the mdoc would have better privacy properties.) So an online research library might reasonably request proof of affiliation, but want to accept either mechanism.  

While it is nice to be able to make invalid requests, like requesting a disjunction of an authentication and identity mechanism, inexpressible, it is only one method of communicating with developers. We expect that browsers would immediately reject any requests that ask for either a passkey or an mdoc (for example), and that communicates the separation pretty clearly too. There is also documentation, language in specs, established norms, etc to communicate the separation.  

Another facet of the design comes from our experience with Web Authentication / passkeys. Web developers really want to be able to pass authentication requests/responses easily to the server, but WebAuthn makes frequent use of ArrayBuffers, which don’t work with JSON.stringify and so do not easily serialize into JSON. Thus one of the goals of the design here is that the request be in the subset of JavaScript that works with standard JSON functions.  

We do propose that this spec be built on top of the IdentityCredential requested through the “identity” option of the Credential Manager API (of which FedCM is built on top of), but not in a way that requires an implementation to also implement FedCM.

This PR was only meant to be a sketch. As you note, it duplicates some bits from other specs where it was clearer to do so, rather than to refer to those documents. Ultimately, all these cases have to be fixed, but at the time we didn't want to distract from the core points. Putting retention as a top-level member was a mistake, one that we already realized some weeks ago, and were intending to address in a follow-up. It seemed like it might be a concept that spans multiple identity mechanisms, but we now feel that keeping mechanisms completely separate is probably best right now.

Speaking of multiple mechanisms, another goal that we have is to ensure that there is space in the API for requesting Verifiable Credentials. We are focused on building an mDL API, but the possibility that Verifiable Credentials will be an ecosystem necessity in the future is real, and we want to ensure that should they need to be supported, it would not damage the API too much.  

So that's why it feels to us like we'll be reducing the risk of having a mess on our hands long term if we put this into navigator.credentials. But as mDL is rapidly gaining traction, we feel some urgency to pick a design so that we can work towards prototyping a first version in the coming months.

Does it seem reasonable if we open an issue in this repo, dedicated to this question, and ask other ecosystem members (including TAG) to weigh in?

[othermaciej]

@agl can you put more of what’s in your comment into the explainer draft in your PR, as well as addressing all the specific points of feedback of bits that are unclear or seem like outright errors? The intent of making a sketch is reasonable, but my understanding is that the Apple folks who originally proposed this spec have been asked to review and merge the PR, and I do not think it is mergeable in its current form.

implied requirements like rejecting any credential request for either a passkey or an mDL should be spelled out, I think. As should details like proposals to change things in FedCM, or to push bits of FedCM down to CM. It was impossible for me to tell which cases were things like that vs simply errors/oversights.

As for an interchangeable request for either an mdoc or a FedCM credential, I still do not understand even with your explanation how that is supposed to work. If it’s supposed to work with this PR and FedCM as it stands, then adding a worked example to the explainer would help. If it’s not supposed to work as-is and would require changes to FedCM proper, then sketching those changes would help. Moving this API to be on top of Credential Management has some clear downsides (more verbosity, makes it possible to express invalid requests) so the rationale for the proposed API shape needs to be understandable even to those who do not have the inside thinking of how FedCM is expected to evolve. So I think more of the context above needs to be in the Explainer and the path to joint use with FedCM needs to be spelled out with more specifics, ideally a code examaple.

I think that, plus fixing the technical errors highlighted in my specific line comments, is a reasonable request before a new round of review of this PR.

[RByers]

@othermaciej, it seems like the key design question to be answered (before spending time on a lot of these fine details) is whether unifying with CM is a good idea or not, right? We've taken your feedback here and updated the discussion in #2, shall we continue there?

I've also updated this PR to align and will respond to each comment individually, but perhaps we should see if we can get some consensus on #2 first before worrying too much about the details here?