Re: Unknowns of the WebAuthn + CredMan merge

Thanks for putting together a comprehensive list of concerns. The google
folks were thinking that it might help to file these as github issues, even
though they're against a PR instead of the current spec, so that we can
iterate on each one, and merge the PR when each one has low enough
uncertainty. I believe Alexei or Dirk was going to start filing their
concerns.

On Thu, Apr 13, 2017 at 1:52 PM, Angelo Liao <huliao@microsoft.com> wrote:

> 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.
>
> I think this is incorrect. #399 makes `rp` (a ScopedCredentialEntity)
required in MakeCredentialOptions, but `id` is still an optional field in
ScopedCredentialEntity.

>
>    -
>       -
>       - 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.
>
> Although of course the browser is free to ignore one of the icons if it
prefers not to change the UX.

>
>    -
>       -
>    - 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.
>
> When the user passes exactly one credential type into credentials.get(),
then the browser can use completely separate UIs for password vs publickey.
When the user passes two credential types, e.g. credentials.get({password:
..., publickey: ...}), then the browser has to do *something* to
incorporate both. There are several options here, but I don't think we've
explicitly drawn one out Mike's first PR banned that combination; the
current one allows it. It's useful to look at GitHub's re-auth page, which
actually uses that combination.

>
>
> 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.
>
> By "don't support bringing this function over", do you mean that you're
unhappy that it exists on the navigator.credentials interface when
public-key credentials exist there, or that you're happy having public-key
credentials ignore calls to requireUserMediation()?

>
>    -
>       -
>    - 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.
>
> Certainly create() can put the public-key credential somewhere the client
can find, but create() isn't the only way that a browser might first
interact with a public-key credential. If the user creates a private key
with a USB or Bluetooth-connected FIDO device on browser 1, and then
attaches that device to browser 2 and calls get() to retrieve a credential
signed by that private key in browser 2, the site should call store() to
inform browser 2 that the credential worked to sign in. This tells browser
2 that it's useful to offer to generate more credentials with that ID.

This is an interpretation of store() that I only discovered last week, and
I owe Mike a PR to describe it in the Credential Manager spec.

Note that the "credential" is just the assertion signed by a private key.
The credential is not the private key that generates the assertions. A
browser could sync the fact that a certain credential ID worked to sign in,
without causing the private key to leave its home TPM.

>
>    -
>       -
>       - 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.
>
> I definitely agree that we shouldn't add APIs that imply the private keys
would leave their TPMs.

>
>    -
>       -
>    - 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.
>
>
It's related in that Credential Manager may want a similar function to
advertise SMS or email credentials, but it's fine to add it to WebAuthn
(probably as a static method on PublicKeyCredential) before Credential
Manager has figured out the generalization.

>
>    -
>       -
>    - 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.
>
> I believe fetch integration for PublicKeyCredentials won't help you cancel
requests to get an assertion. However, the fetch() folks are working on a
general way to cancel things across the web platform, and what they've
coming up with naturally fits into the options dictionary for any plausible
WebAuthn API.

>
>    -
>       -
>
>
>    - 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.
>
> Agreed.

Now, where I have I gotten stuff wrong. :)

Jeffrey


>    -
>
>
>
> 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:
>
>    1. Introduction
>       2. Conformance
>       3. Terminology
>       4. Web Authentication API
>       5. WebAuthn Authenticator Model
>       6. Relying Party Operations (as long as the content of the returned
>       object won’t be impacted)
>       7. Defined Attestation Statement Formats*
>       8. WebAuthn Extensions (all extension points will be preserved
>       after all)
>       9. Defined Extensions
>       10. IANA Considerations
>       11. Sample scenarios
>       12. 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
>
>
>
>
>