Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add one-time-code autocomplete field #3745

Closed
hober opened this issue Jun 6, 2018 · 14 comments
Closed

Add one-time-code autocomplete field #3745

hober opened this issue Jun 6, 2018 · 14 comments
Labels
addition/proposal New features or enhancements topic: forms

Comments

@hober
Copy link
Contributor

hober commented Jun 6, 2018

Sites often require users to demonstrate their identity by providing a one-time-code that is sent to the user out-of-band. For example, the site may email the user's email address on file, or send and SMS to the user's known phone number.

Manually typing such codes into sites is cumbersome and error-prone. We propose the addition of a one-time-code autocomplete field name to help UAs automatically fill such fields to improve this.

Field name Meaning Canonical Format Canonical Format Example Control group
"one-time-code" One-time code used for verifying user identity Free-form text, no newlines 123456 Password
@hober
Copy link
Contributor Author

hober commented Jun 6, 2018

This is implemented in Safari 12 on macOS 10.14 and iOS 12.

@annevk annevk added addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest topic: forms labels Jun 6, 2018
@domenic
Copy link
Member

domenic commented Jun 6, 2018

I'm a little unclear how strictly we should apply the implementer interest criteria for autofill field standardization. But hopefully we can get multi-implementer interest and not have to even worry about it...

@annevk
Copy link
Member

annevk commented Jun 7, 2018

@mnoorenberghe thoughts for Firefox? I guess the main reason we don't have this in HTML right now is because 2FA came after this was initially standardized?

@mnoorenberghe
Copy link

I saw this the other day on developer.apple.com and thought it made sense to add to HTML. We've had bugs filed before to not save these fields in form history or in password manager because they aren't going to be useful so one-time-code could aid in solving that… The risk in using it for that purpose is that it will be (ab)used on regular password fields to prevent saving/filling non-one-time-use passwords. Some of those same concerns already apply to new-password, though ideally in that case a browser password generation UI could discourage abuse… I'm not sure how we could discourage that type of abuse for this value yet.

Overall I think the addition makes sense, especially where a password manager will help to fill the field, rather than just avoid filling something else (e.g. the user's regular password for that origin), I just worry it will be abused by websites that try to work against password managers… hopefully that will end one day. +1 from me

@tomayac
Copy link

tomayac commented Jun 7, 2018

The risk in using it for that purpose is that it will be (ab)used on regular password fields to prevent saving/filling non-one-time-use passwords.

People do this with the autocomplete="off" (docs) attribute already, albeit browsers have begun to ignore this.

@annevk annevk removed the needs implementer interest Moving the issue forward requires implementers to express interest label Jun 7, 2018
@mikewest
Copy link
Member

mikewest commented Jun 7, 2018

Hey folks!

I think adding one-time-code as an autocomplete attribute is reasonable. I can imagine password managers that support TOTP making good use of it, for instance. For that kind of use case, it seem pretty reasonable. I'm a bit more skeptical about the SMS use case cross-platform. For example, on platforms like Android each browser would need to grab SMS permissions and scan through incoming messages to autofill the field, which we'd like to avoid doing.

Android offers an lower-privilege SMS Retriever API that we're interested in exploring, however: https://developers.google.com/identity/sms-retriever/overview. That's a platform-level API that waits for incoming messages that meet a certain template, and passes just those messages on to the relevant application. That is, the platform would give Chrome a short hash, we'd lengthen it to include origin-level routing information, and give the developer an SMS template string, perhaps something like:

<#>
%s

---
random-token-that-identifies-the-origin-and-renderer
token-that-identifies-the-Chrome-app

The developer could use the Credential Management API to grab a Promise that would resolve when the SMS came in, and send the codes gathered back up to the server for verification.

We'd sketched out an API along the lines of:

// On Android, |smsTemplate| would contain something like "<#>\n%s\n[tokens and stuff]".
// Presumably other platforms would have their own variants based on the underlying
// platform API (iOS might hand over `Code: %s`, for instance).
let smsTemplate = SmsCredential.getMessageTemplate();

navigator.credentials.get({ "sms": true }).then(c => {
  // This promise will resolve when an SMS matching |smsTemplate| is received and routed
  // to the browser by the underlying platform.

  // `SmsCredential.text()` returns the body of the SMS message, stripped of any required
  // prefix and suffix (e.g. `<#>` and the one-time-token on Android).
  let text = c.text();

  // The application can now verify the message by POSTing something to the server.
  let init = { method: "POST", body: text, credentials: "include" };
  fetch("https://same-origin.example/verify-sms/", init)
      .then(r => {
          // If |r| is valid, do cool, validated things. If not, don't.
      });
});

// Once the handler is set up, tell the server to send the user a message (presumably
// the server knows the user's phone number...)
let init = { method: "POST", body: smsTemplate, credentials: "include" };
fetch("https://same-origin.example/send-sms", init);

Would y'all interested in exploring that kind of lower-privilege, imperative approach? I think it has some security advantages that I find pretty interesting.

@mnoorenberghe
Copy link

mnoorenberghe commented Jun 7, 2018 via email

@hober
Copy link
Contributor Author

hober commented Apr 26, 2019

I added the needs implementer interest keyword, though perhaps @mnoorenberghe's "+1 from me" is sufficient to pass the multi-implementor-interest bar.

@mnoorenberghe
Copy link

mnoorenberghe commented Apr 26, 2019

FWIW I almost added some support for this in Firefox a few months ago but hesitated since it wasn't in the spec yet. We will likely only use it for the following in the foreseeable future:
a) Don't save the value in form history
b) Don't autofill passwords into it (we will still allow the user to fill a saved password with user interaction to mitigate potential abuse that I mentioned earlier)

@hober
Copy link
Contributor Author

hober commented Apr 26, 2019

That definitely sounds like implementor interest, then. :) Removing the keyword.

@hober hober removed the needs implementer interest Moving the issue forward requires implementers to express interest label Apr 26, 2019
@domenic
Copy link
Member

domenic commented Apr 26, 2019

Sounds like we should add this to the spec! Although I think it's a little weird that it sounds like Firefox's plan for implementing is to just treat it as autocomplete=off?

But as I briefly noted up thread, autofill is a weird area, so as long as we have multiple browsers who want to consider this field special in some way, we should land something in the spec that the ecosystem can coordinate around.

@hober
Copy link
Contributor Author

hober commented Apr 26, 2019

Okay, I have the spec change & WPT update mostly prepped locally. I'll submit a PR soon.

@jyasskin
Copy link
Member

@hober, if I'm a website author, your specification doesn't tell me enough to know how I should send an SMS that'll actually autofill on the user's platform. Do I need to user-agent-sniff to get the right format on iOS vs Android? Is @mikewest right that browsers on Android can't auto-fill this at all?

@annevk
Copy link
Member

annevk commented Apr 30, 2019

@jyasskin it'd probably be best to track that separately at this point, given this was merged.

pull bot pushed a commit to FreddyZeng/chromium that referenced this issue Feb 13, 2020
…ransport:["sms"]}})

This change introduces the otp option for credential manager.
The shape is as shown below, and is behind the SmsReceiver flag. This
implementation piggy backs on top of previous implemented version of
SMS Receiver API, now renamed to WebOTP API.

navigator.credentials.get({otp: {transport: ["sms"]}}).then((credential) => {
  let type = credential.type; // "otp"
  let id = credential.id; // otp string ex. "ABC1234"
});

Tested: locally, browsertests, wpt

Relevant resources:
Explainer: https://github.com/samuelgoto/WebOTPs/blob/master/explainer.md
Early discussions: whatwg/html#3745 (comment)
Discussed alternatives: https://github.com/samuelgoto/WebOTPs/blob/master/explainer.md#api-alternatives-considered
Design Doc for Sms Receiver API(V1): https://docs.google.com/document/d/1dB5UM9x8Ap2-bs6Xn0KnbC_B1KNLIUv4W05MunuXYh0/edit?usp=sharing
OT of Sms Receiver API(V1): https://developers.chrome.com/origintrials/#/view_trial/607985949695016961

Bug: 1045233
Change-Id: I4b68f08f2b26047809f6dcf84cbd82245e741f4b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2018331
Commit-Queue: Ayu Ishii <ayui@chromium.org>
Reviewed-by: Victor Costan <pwnall@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#741190}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition/proposal New features or enhancements topic: forms
Development

No branches or pull requests

7 participants