Unknowns of the WebAuthn + CredMan merge

Apologize for the ridiculous length of the mail. I hope you have the patience to read through.

Hi Everyone,

Alexei's recent comment about concern over the unknown led me to wonder what unknowns are actually out there once the merge exists. As common in all engineering works, unknown will exist and it is our job to name the unkowns. (Before I start, I figure I spend some time summarizing the current status of the merge. See this doc<https://docs.google.com/document/d/1zwyW0RBgm_OoTzqLr4bIJHvOLmkCCinSqMZdN-7KW8Q/edit?usp=sharing> for the summary. I have also heard of concerns from the TAG recently about this so hopefully this will help them understand the current situation. Please correct me if I got something wrong. )

As we look at the summary doc<https://docs.google.com/document/d/1zwyW0RBgm_OoTzqLr4bIJHvOLmkCCinSqMZdN-7KW8Q/edit?usp=sharing> above, I think we can all agree that 90% of the proposals are renaming and building up inheritancy structure that contain the same objects. Of course I am not the biggest fan of layers of dictionaries but this API will require such layers anyway. However, the proposals do bring forth changes that impact the functionality, i.e. real change to the implementation logic:

  *   https://github.com/w3c/webauthn/pull/399/files
     *   The rpId is now a required field, moving its status up from an optional field.
     *   The imageURL used to be only for user account avatar icon. But now the rp supplies both its own logo icon and the user account avatar icon, leading to potential UX change.
  *   PR #384<https://github.com/w3c/webauthn/pull/384>:
     *   makeCredential now has to return the id, type, and rawID
     *   getAssertion now has to return a base64encoding version of the id, in addition to type and rawID
  *   Alexei's Proposal
     *   makeCredential now has to return the id, type, and publicKey, which needs to be extracted from the authenticator somehow.
     *   GetAssertion now has to return publicKey

  *   In addition to the API changes mentioned, one change is worth noting: will the UI of CredMan be shared with that of WebAuthn?
     *   To me, that's a rather platform-specific thing. Of course we can all agree that the account chooser interface that CredMan brought forth is superior than the traditional NASCAR-like interface. To me, if any platform wants to allow user to choose one account type, that UI will resemble the account chooser interface. It is then up to the platform to decide whether they want to re-use the same code.

Now that we look at all the changes brought forth by the proposals, let's look at all the possible changes in the future. I will start with all the functions outside of makeCredential and getAssertion in both interfaces and move on to the rest. To clarify, I personally don't think adding them is necessary right now. They are functions that could be added later. The proposals above brings the benefits to the table without moving the following functions around. If none of us who has been work on the two specs for a long time, it is likely because we haven't seen a value in it.

  *   requireUserMediation from CredMan
     *   The user mediation flag from CredMan, if set, will prompt a dialog asking the user to confirm the user wants to sign in. The assumption behind such flag is that the user can be silently signed in without user interaction. Whether authentication with strong physical devices, such as Yubikey, can be done through user interaction is the debate at hand. The security protection, privacy issue, the user experience of bringing this flag to WebAuthn is up to debate. However, this is an additive change that can be done in the future.
     *   As Tony suggested, we at Microsoft haven't heard of an RP asking for silent auth with a physical device. Therefore I don't support bringing this function over. Of course, if we do observe an indication of such request, we can add this function.
  *   store from CredMan
     *   Store function does two things: 1) put the credential into a place that the client can find, 2) make the credential roam among browser instances. The first thing is done by the create function already.
     *   I don't believe letting credentials roam around or use a cookie to maintain users signed-in between instances is consistent with our security story. An aspect of the TPM security protection is that the credentials don't really leave the device. This is a deviation from that principle.
  *   isPlatformAuthenticatorReady from WebAuthn
     *   isPlatformAuthenticatorReady enables RP to search to see if there exists a WebAuthn-ready devices and prompt user to confirm letting the RP knows the device exists. I don't believe this is related to CredMan.
  *   possible cancel proposal from WebAuthn
     *   The cancel method enables RP to cancel authentication operation if a single-page site moves away from something without a navigation event. The goal of the cancel method may also be achieved if fetch is integrated.
     *   I believe the functionality of the cancel method is important. However, if we can achieve this with fetch integration, we shouldn't have to worry about it.

  *   There are also proposals from Jeffrey about the potential functions that could surface after the merge succeeds. However, I see those proposals as additive to the existing spec and not in scope of the current discussion.

Of course, as a spec guy, I share all of your concerns about making significant shifts to the spec and rewriting everything. The merge indeed seems big and daunting, especially with our 80 pages long spec. However, after some more considerations, we can see the change won't impact the spec much. We have 15 sections in the spec so far. Most sections won't be impacted:

     *   Introduction
     *   Conformance
     *   Terminology
     *   Web Authentication API
     *   WebAuthn Authenticator Model
     *   Relying Party Operations (as long as the content of the returned object won't be impacted)
     *   Defined Attestation Statement Formats*
     *   WebAuthn Extensions (all extension points will be preserved after all)
     *   Defined Extensions
     *   IANA Considerations
     *   Sample scenarios
     *   Acknowledgement
*: As what we agreed so far, the underlying protocol layer won't be changed as part of this.

Overall, I see quite a benefit in having a clean API interface for login scenarios on the Web. This would reduce confusion among developers, with the potential of increasing WebAuthn adoption in passwordless login. The PR also opens up the possibility for getAll in the future to address multi-factor authentication, which, as I was told by the surface team, is starting to be an industry trend.

I am happy to be proven wrong. But please tell me where I am wrong.

Angelo