W3C home > Mailing lists > Public > public-webauthn@w3.org > September 2019

Re: [webauthn] Supply an “intention" member in PublicKeyCredentialCreationOptions dictionary (#1292)

From: Jiewen Tan via GitHub <sysbot+gh@w3.org>
Date: Wed, 18 Sep 2019 18:02:47 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-532798553-1568829766-sysbot+gh@w3.org>
We think it is a good idea to provide a guideline to map different options into a relatively limited set of high level intents. However, it is very hard to confirm the inferred intent from a set of options. For example, options { Platform, RKPreferred, UVRequired } can be used as either a first factor or second factor. It is up to the RP. And it will be very awkward that the user agent infers the combination as Passwordless* and thus suggests it in the UI to users while the RP itself actually suggests SecondFactor* in its UI. Also, it could be very subtle for RPs to tune the options to display a user agent UI they want.

Thus, we propose instead of deducing those high level intents from an option map, a high level intent member as described above should be provided not just to help user agents to phrase their UI but also to initialize those options. Here is the new proposal.

******

```
dictionary PublicKeyCredentialCreationOptions {
    …
    CredentialCreationIntention intention;
};

```
intention, of type CredentialCreationIntention
&nbsp;&nbsp;&nbsp;&nbsp;This OPTIONAL member contains the purpose of the relying party to create the public key credential. This initializes authenticatorSelection to values that match the intention and also allows the user agent to better describe the intention in its own UI. Noted, values provided to authenticatorSelection will overwrite values initialized by setting this member.

```
enum CredentialCreationIntention  {
    “sole-first-factor”,
    “alternative-first-factor”,
    “second-factor”
};
```

A public key credential created by this API can be used for various different purposes. This enumeration defines intentions as to how the about-to-create credential will be used.

**_sole-first-factor_**
&nbsp;&nbsp;&nbsp;&nbsp;Indicates the intention is to use the public key credential as the only factor for authentication. If a password is used previously, this indicates the about-to-create credential will replace that password. This value initializes authenticatorSelection to {  residentKey: “required”, userVerification: “required” }.
**_alternative-first-factor_**
&nbsp;&nbsp;&nbsp;&nbsp;Indicates the intention is to use the public key credential as an alternative method for authentication. If a password is used previously, this indicates that either the password or the about-to-create credential could be used for any given authentication. This value initializes authenticatorSelection to {  residentKey: “preferred”, userVerification: “required” }.
**_second-factor_**
&nbsp;&nbsp;&nbsp;&nbsp;Indicates the intention is to use the public key credential as a second factor together with other factors for authentication. If a password is used previously, this indicates the about-to-create credential will be used together with that password. This value initializes authenticatorSelection to {  residentKey: “preferred”, userVerification: “preferred” }.

\* Terms from [#1300](https://github.com/w3c/webauthn/pull/1300).

******

A few things to clarify:

1) We have considered to add “re-authentication” to the enum, but we feel like it collapses a lot with “alternative-first-factor”. Also, it doesn’t seem to make any sense to set authenticatorSelection.residentKey to “discouraged" with authenticatorSelection.authenticatorAttachment being set to “platform”.

2) For “Typing-free”, we think it is a separate topic than what we propose. What we propose is a way to describe the fundamental functionalities of the public key credential and set authenticatorSelection accordingly. “Typing-free” is more of a way of how the authenticatorSelection could affect RPs’ user experience, i.e. whether they would ask users for their username or not. We are very interested to assist RPs to make this relation more clear but not within this proposal.

3) For getAssertion, we think the intention is very clear and the PublicKeyCredentialRequestOptions is less complex than PublicKeyCredentialCreationOptions, and therefore no further clarifications are needed. Of course, we welcome different thoughts on getAssertion and will like to improve it together.

-- 
GitHub Notification of comment by alanwaketan
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1292#issuecomment-532798553 using your GitHub account
Received on Wednesday, 18 September 2019 18:02:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:59:07 UTC