What kind of same-site rule is appropriate?

[hober]

The explainer currently says:

Any origin which is schemelessly same site as [the origin specified in the SMS] is an origin on which this code may be used.

Should this really be schemelessly same site, or should we tighten it a bit to (schemefully) same site?

[mhardeman]

While this might expand beyond the scope of WebKit, schemelessly perhaps makes sense if there's some interest in binding the functionality to more than just web pages.

As to scheme where it would apply to WebKit, perhaps OTP autocompletion should only be offered or succeed on https origins anyway. If so, eliminating characters in the SMS message is desirable as native max message size is small in SMS.

But if, for example, an app wanted OTP confirmation, being schemeless might signal allowing an App which has authenticated as belonging to/with the stated origin to utilize the autocomplete?

At least in the Apple ecosystem, there are already mechanisms for binding DNS identifiers in an authenticated manner to apps (for several purposes). Perhaps a DNS identifier as origin here would achieve the same outcome for an app which has that same entitlement?

[riking]

Requiring a scheme would also inflate the payload size if a human-readable format is used.

[mhardeman]

Agreed on the payload inflation -- presumably you'd want the feature to only supply the OTP via mechanisms the platform regarded as secure anyway.

[rmondello]

As to scheme where it would apply to WebKit, perhaps OTP autocompletion should only be offered or succeed on https origins anyway. If so, eliminating characters in the SMS message is desirable as native max message size is small in SMS.

For web content, an origin-bound one-time code should be understood to be intended for a secure context.

At least in the Apple ecosystem, there are already mechanisms for binding DNS identifiers in an authenticated manner to apps (for several purposes).

Just to clarify for others, Apple’s machinery for associating apps with a website (origin) is called associated domains. I understand that Android has a similar mechanism.

[annevk]

If we are to go with this I'd somewhat prefer a same origin default/option. And yeah, maybe not offer the feature without secure contexts as it becomes very brittle then.

[mikewest]

If a server intends to allow sign-in on an HTTPS site, it would be Bad™ for that OTP to leak by being made available on an HTTP page that is both visible to and controllable by everyone on the network between the user and the server. To me, that means we need to respect the scheme of any origin asserted by the sender.

Similarly, it's not clear to me why it would be valuable to allow an OTP targeting one origin (https://accounts.google.com/) to be delivered to another with radically different security needs (e.g. https://archive.google.com/intl/en/press/zeitgeist2007/). I recognize that browsers do this today with password autofill (and there's good reason to do so!), but OTP seems different in kind, as the server surely knows the exact origin the user's looking at when they send out the verification code, and can assert it accordingly. To me, that means we should not make a same-site comparison at all, but run with @annevk's suggestion of same-origin.

[hober]

@mhardeman wrote:

As to scheme where it would apply to WebKit, perhaps OTP autocompletion should only be offered or succeed on https origins anyway. If so, eliminating characters in the SMS message is desirable as native max message size is small in SMS.

@riking wrote:

Requiring a scheme would also inflate the payload size if a human-readable format is used.

Ahh, I think there's a misunderstanding here. The syntax doesn't have to specify a scheme, merely a host. When parsed, we end up with an origin whose host matches what was in the message, and whose scheme and port are "https:" and "" respectively. Regardless of what same-site rule we end up going with, the syntax doesn't have to change.

[hober]

If a server intends to allow sign-in on an HTTPS site, it would be Bad™ for that OTP to leak by being made available on an HTTP page that is both visible to and controllable by everyone on the network between the user and the server.

This strikes me as an excellent argument against schemelessly same-site. I'll update the PR accordingly, but I'm gonna leave this issue open as I think we should continue to discuss the same-origin v. same-site question.

[hober]

Circling back on this, I think I've partially changed my mind from last week. I think we should

• define these as origin-bound (as we currently do)
• drop all existing language about same-site
• add some new text describing the pros and cons of where a tool might use origin-bound codes (best to worst: same origin, same site, schemelessly same-site, and cross-origin). Something like the table below. Like @mikewest says above, "browsers do [same site] today with password autofill (and there's good reason to do so!)" I think the best thing to do is to help implementers make an informed decision.

(For same origin and same site in the below table, I'm assuming it'd be secure contexts only.)

option	pros	cons
same origin	best option phishing-wise	less utility for common same-org auth flows
same site	works for some more same-org auth flows	not great for mike's "same site but radically different security needs" scenario
schemelessly same site	works for even more same-org auth flows	susceptible to MITM attack
cross-origin	works best for cross-org auth flows	susceptible to MITM attack, worst option phishing-wise

[annevk]

How would developers know what to rely on?

[hober]

How would developers know what to rely on?

I think we're gonna need RFC2119 SHOULD-level language here. It'd be great if it could be a MUST, but we know (given shipping behavior in several password autofill implementations) that "that there may exist valid reasons in particular circumstances to ignore [the requirement]," so SHOULD it is.

Here's a quick straw person proposal, which I'll try to return to later today to provide additional rationale:

option	RFC2119 term	rationale
same origin	?	?
same site	SHOULD	strikes me as the best balance
schemelessly same site	?	?
cross-origin	SHOULD NOT	the riskiest of the options

[rmondello]

Thinking as an implementer for a moment, here’s what I suspect a sensible policy would be:

• Same origin: allow assisting the user with providing the code to the website.
• Same site, but not same origin: allow assisting the user with providing the code to the website, but indicate in the UI which website the code is intended for (the origin from the message).
• Cross-origin: do not assist the user with providing the code to the website.
• In all cases, non-secure origin: do not assist the user with providing the code to the website.

This is consistent with some Password AutoFill implementations, which save credentials per-origin (analog: origin in the message), but offer them same-site (but label them when they’re doing so).

[hober]

The spec matches @rmondello's suggested policy. I'm going to close this issue here. If, after reviewing the spec text, people still have concerns on this topic, please file an issue in the spec's dedicated repo.