Allow origin-bound one-time code to be on the same line as the explanatory text

[yi-gu]

Currently the origin-bound one-time code messages can optionally begin with human-readable explanatory text. When such text is in place, the origin-bound one-time code must be on a new line (last line). The benefits are obvious (easy to distinguish from explanatory text, easy to parse etc.)

Problem
We found that the newline character from SMS is not very reliable. e.g. it may get translated into whitespace by SMS carriers / aggregators due to different encoding. We have seen several partners encountering this issue with the WebOTP API and we suppose Safari may have similar observation. In addition, many partners prefer not to use newlines in their SMS due to this particular reason along with other reasons.

Proposal
We suggest dropping the newline requirement from the SMS and allow origin-bound one-time code to be on the same line as the explanatory text. Here are some examples.

Valid origin-bound one-time code message as of today

747723 is your ExampleCo authentication code.
@example.com #747723

747723 is your ExampleCo authentication code.
@example.com #747723 sent by ExampleCo

@example.com #747723   Your ExampleCo authentication code is 747723.

Proposed valid origin-bound one-time code message

747723 is your ExampleCo authentication code. @example.com #747723

747723 is your ExampleCo authentication code. @example.com #747723 sent by ExampleCo

747723 is your ExampleCo authentication code. @example.com #747723 sent by @ExampleCo

[yi-gu]

@hober @erynofwales @rmondello @samuelgoto @majido FYI

[yi-gu]

Hi @hober . Does this make sense in general? I could draft a PR if so :)

[erynofwales]

Hi @yi-gu. You said you've heard from several of your partners. How urgent is this? And when would you want to make this change?

There are two aspects of your proposal that I think merit some thought: how it changes the complexity of the parser, and how it changes the compatibility story for apps and websites.

The parser would have to accommodate domain bindings that start at the beginning of a line (the existing behavior) and somewhere in the middle of a line. I think it would make sense to start parsing at the first @ on the line, rather than try to walk back from the end of the line to find the last occurrence of domain binding info.

The compatibility story for developers is kinda tricky. If we remove the newline requirement, developers will be able to send single line messages, but in order to do so they have to know that their users' devices will be able to parse those messages. The spec right now requires that the domain binding info to be on a line by itself, and that the line begin with an @. If developers want to send a single line message that is also compatible with current parsers, the single line must begin with domain binding info:

@example.com #123456 from ExampleCo.

If they don't care about backward compatibility, they can send messages like this:

747723 is your ExampleCo authentication code. @example.com #747723 sent by ExampleCo

If they don't care about single line messages, i.e. they know their users' SMS carriers can handle newlines, they can continue to send multiline messages and be compatible with past and present versions of the parser:

747723 is your ExampleCo authentication code.
@example.com #747723 sent by ExampleCo

I think there's a lot of opportunity for confusion when we make a big change like this. So I think this would need some very clear communication about how to decide which style of message to send.

One last thing: I saw in the last of your examples that you included an @ in front of "ExampleCo". Is that intentional?

[yi-gu]

Hi @yi-gu. You said you've heard from several of your partners. How urgent is this? And when would you want to make this change?

The current Chrome implementation accepts this single line format and we noticed this issue on some partner sites when we tried to enforce the new line requirement. e.g. paypal.com, tinder.com, housing.com. We learned that some of them sent single line SMS intentionally and some of them didn't. i.e. they sent out multi-line SMS per spec but due to encoding issues their users may receive the content in a single line.

One thing I wasn't clear earlier is that the proposal is actually about improving interop and depending on how we want to achieve this interop we may need to pay backward compatibility cost one way or the other. Basically either Chrome implementation changes to be more restrictive, or Safari implementation changes to be more accepting.

How does Safari handle a single line SMS today?

• If it's spec compliant and reject such SMS, I'm afraid it's suffering from the mentioned issue as well. (Note that users may still see an OTP on the keyboard when such malformed SMS arrives on iPhone but that is probably based on heuristics which is against the website's security expectation of using "origin-bound one-time code")
• If it accepts single line SMS, the interop issue is less worrisome and so is updating the spec.

There are two aspects of your proposal that I think merit some thought: how it changes the complexity of the parser, and how it changes the compatibility story for apps and websites.

The parser would have to accommodate domain bindings that start at the beginning of a line (the existing behavior) and somewhere in the middle of a line. I think it would make sense to start parsing at the first @ on the line, rather than try to walk back from the end of the line to find the last occurrence of domain binding info.

Parsing from the first occurrence of @ sounds good. One caveat is that if the SMS looks like

747723 is your @ExampleCo authentication code. @example.com #747723

we probably should repeat the process until domain and code are parsed or the process is failed.

The compatibility story for developers is kinda tricky. If we remove the newline requirement, developers will be able to send single line messages, but in order to do so they have to know that their users' devices will be able to parse those messages.

Yes. This is the most tricky part in this proposal. I am only aware of two parsers that currently implement this:
Android/Chromium: In this case this is not an issue. Since as I mentioned it already parses the proposed single-line format and the reason for this proposal is to maintain backward compatibility.
iOS/WebKit: This could be very tricky depends on how Safari handles single line SMS.

The spec right now requires that the domain binding info to be on a line by itself, and that the line begin with an @. If developers want to send a single line message that is also compatible with current parsers, the single line must begin with domain binding info:

@example.com #123456 from ExampleCo.

This requires that the human readable content comes after the machine readable content which is spec-compliant but less preferred by developers especially when the human readable content is likely trimmed by the SMS notification on the phone.

If they don't care about backward compatibility, they can send messages like this:

747723 is your ExampleCo authentication code. @example.com #747723 sent by ExampleCo

If they don't care about single line messages, i.e. they know their users' SMS carriers can handle newlines, they can continue to send multiline messages and be compatible with past and present versions of the parser:

747723 is your ExampleCo authentication code.
@example.com #747723 sent by ExampleCo

I think there's a lot of opportunity for confusion when we make a big change like this. So I think this would need some very clear communication about how to decide which style of message to send.

Yes. We should be cautious if such change is considered necessary for reasons mentioned above and come up with a tangible solution.

One last thing: I saw in the last of your examples that you included an @ in front of "ExampleCo". Is that intentional?

Yes it was intentional to include a possible case with @ and it should be a valid SMS per spec today. Note that it's not the same as iframe.