Consider adding a syntax identifier and code type to the message

[a2sheppy]

I'd like to suggest adding a component to the message that can be used to easily and quickly detect that the message is intentionally in this format, rather than having to parse the message and hope it isn't just coincidentally similar to this format.

Considering the example from the explainer: ` 747723 is your FooBar authentication code.

@foobar.com #747723 `

I suggest changing the last line so the message looks something like: ` 747723 is your FooBar authentication code.

SMSID/1.0 @foobar.com OTP#747723 `

SMSID indicates that the message is indeed in this format, and the 1.0 is the syntax version. This helps to future-proof the format by allowing for future syntax changes to be made safely.

OTP is a code type ID added before the # sigil to indicate that the code is a one-time password. This could become relevant if, sometime in the future, it becomes useful to support other types of authentication systems using SMS responses. For example, the code ID PIN could be used to indicate that the value is a PIN number.

The addition of the code type ID lets this format be used by an online banking app that uses an OTP for login, but also uses SMS to send users a temporary PIN for their credit or debit card, in situations where they need to change it or such:

` 7193 is your new Bank of Frobozz debit card PIN.

SMSID/1.0 @frobozzcobank.com PIN#7193 `

Now the bank app can see the message and correctly route the number to either the login code or to code that records the PIN for future reference.

This could just as easily be used for sending temporary passwords for use during password resets, etc, by using a code type ID denoting such.

[mhardeman]

I, too, have suggested something similar in a comment on Issue #9, at https://github.com/WebKit/explainers/issues/9#issuecomment-58010351

I think making it easy for a messaging application to recognize the intent of an SMS per the proposal may be essential to making it safe to handle the message with special UI considerations.

I think it's important that a message with an OTP code to be handled as set out in the proposal be identifiable unambiguously as either "not being a message intending to participate in this proposal's mechanism for OTP signaling" or "the logical OR of a message intending to participate in this scheme OR a message in bad faith."

[hober]

I think the syntax we propose is sufficient to signal the intent of the SMS. As far as extensibility goes, the explainer doesn't currently cover this, and probably should. I'll write a PR to add the relevant text. Thanks!

[mhardeman]

I'd like to express a concern as to the nature of the proposed extensibility fix. In the absence of a sentinel/protocol indicator as described earlier and/or as in a comment on issue #9, the pull request changes the format to allow for even more ambiguity, as it is no longer necessary for the format in the proposal to be the explicit end of the message, making it even more possible for accidental matches or bad-actor initiated matches to occur.

This would shift a plausible regex from having been "\n@.+ #[0-9]+$" to now being "\n@.+ #[0-9]+"

[hober]

the pull request changes the format to allow for even more ambiguity, as it is no longer necessary for the format in the proposal to be the explicit end of the message

It was always our intention to allow this extensibility point, and to make sure the spec allows for it by permitting arbitrary text on the line after the known parts. This just wasn't spelled out in the explainer, which is my fault; I was thinking of it as a parser detail, and that level of detail seemed inappropriate for an explainer.