search

WICG / sms-one-time-codes

A way to format SMS messages for use with browser autofill features such as HTML’s autocomplete=one-time-code.
https://wicg.github.io/sms-one-time-codes/
Other
110 stars 12 forks source link

Third-party authentication / nested iframes #4

Closed hober closed 3 years ago

hober commented 4 years ago

Lots of sites embed an iframe from a different origin that handles authentication for them. This is sometimes a third party, or maybe it's a separate service run by the same party. One obvious example is icloud.com, which uses apple.com for authentication.

Should we support such cases? If so, why, and how would the spec need to change? If not, why not?

samuelgoto commented 4 years ago

Should we support such cases? If so, why, and how would the spec need to change? If not, why not?

Good question. We chose to deliberately ignore this problem early on because we didn't find enough demand that outweighted the risk / complexity, but happy to reopen this discussion if you find important.

Questions:

hober commented 4 years ago

Should we support such cases? If so, why, and how would the spec need to change? If not, why not?

Good question. We chose to deliberately ignore this problem early on because we didn't find enough demand that outweighted the risk / complexity, but happy to reopen this discussion if you find important.

We've had a few customers/clients ask for this.

  • what other alternatives have you considered? in the icloud.com use case with apple.com, would SameSite or FirstPartySites help?

It might help for cases where it's the same organization, but the third-party authentication service case is more common, and FPS wouldn't help with them. (I also doubt FPS is a good idea to add to the platform in general.)

  • from a demand perspective, who is pulling this?

I don't understand the question.

  • how would this work once third party cookies get further constrained?

I don't understand what third party cookies (or cookies in general) have to do with this. Could you elaborate?

  • from a spec perspective, should this go into whatwg/html or wicg/WebOTP instead?

I don't think so. This spec should define the format and any delivery-mechanism-agnostic usage guidance. If there were additional guidance specific to one of the delivery mechanisms, then that mechanism's spec should do that.

  • what would prevent largely deployed widgets (say, an ad network) from sending SMSes to track users?

Why would a user provide such a code to such an iframe?

samuelgoto commented 4 years ago

One obvious example is icloud.com, which uses apple.com for authentication.

how would this work once third party cookies get further constrained?

I don't understand what third party cookies (or cookies in general) have to do with this. Could you elaborate?

In the use case you mentioned, which origin is the recipient of the OTP? apple.com? that is, i'm assuming the setup is something along the lines of:

// owned by icloud.com
<html>
  <iframe src="apple.com">
    <input autocomplete="one-time-code">
  </iframe>
</html>

And the SMS is formatted more or less like:

@icloud.com @apple.com #1234

Is that the right setup?

If so, is it fair to assume that the apple.com iframe is receiving the SMS OTP? Is the apple.com iframe communicating with the icloud.com top level frame? If so, how? postMessage? Out of band? if in-band, i'm assuming the apple.com domain isn't getting any access to its third party cookies?

majido commented 3 years ago

I like to get a resolution on syntax and semantic for this proposal here as we are looking into implementing this in Chrome (crbug) as well. I am told that Safari is supporting this usecase starting from iOS14. So landing on a consensus sooner is better.

Syntax

Option 1

@top #code %iframe

As proposed in earlier PR. I am told that Safari in iOS14 is already supports this syntax. So this is the de-facto standard at this point but perhaps it can change if there is interest to do so.

Pros:

Cons:

Option 2

@top #code @iframe

Similar to Sam's proposal here but more backward compat to existing spec compliant implementations

Pros:

Cons:

Option 3

@top @iframe #code

This is Sam's proposal

Pros:

Cons:

Backward Compat Concern on changing syntax

If we decide on either (2) or (3) then we have to think carefully about backward compat during the transition period. I have some ideas on how to make such a transition easier but there are challenges. But if there is interest/possibility to go for (2) or (3) then we can come up with more concrete plan here.

Nesting level

Is the intention only to allow one level nesting or are we going to allow arbitrary nesting? For example consider this nesting "top > iframeA> iframeB", does iframe B get access to WebOTP feature?

I suspect we prefer arbitrary as I don't yet see any compelling reason to limit it to just one. So yes!

If this is so then should the sms include any intermediate iframe domain as well (e.g., @top #code %iframeA %iframeB)? The current proposed PR only talks about top level origin and embedded origin.

The answer to this may also be factor into syntax consideration as well since if we allow arbitrary having a single token for all domains may make more sense. We may also want to remove any "ordering" between origins.

erynofwales commented 3 years ago

I think Option 2 in @majido's previous comment is a great way to go. I like that we're preserving backward compatibility with the ordering of fields. Using the same sigil for top-level and iframe domains makes sense here too.

To the iframe ordering question, I don't think we need to be completely explicit about the ordering. It seems sufficient to make sure that the URLs of all involved frames, from the page down to the frame containing the one-time code field, match one of the @ fields. I suspect the vast majority of cases will not need more than two @ fields in an SMS, but it seems reasonable to me for the parser to allow as many as the service requires to validate the chain of frames.

majido commented 3 years ago

That is great. I think we should move forward with Option 2.

I am also fine with limiting to two origins but allowing arbitrary nesting levels. Our current implementation is slightly stricter than that. In particular when we receives an OTP sms such as @A #code @B we apply the following requirements:

I don't recall why we made it more restrict but I will try to dig and find out and share the rationale.

So I think we should be able to move forward with adding this to the spec.

yi-gu commented 3 years ago

The chain limitation (A>B>A not supported) was mainly due to the lack of demand and UX complexities which brings me to my following questions w.r.t. some privacy / security concerns.

Should users be aware of the iframe?

e.g. a user is visiting shop.com but when they interact with the OTP they are actually interacting with payment.com which may be against their intention. Should the user be informed of such implication? According to the linked PR:

If the above steps returned "site", it might be prudent to indicate the [=origin-bound one-time code=]'s top-level and embedded origins to the user when assisting them

IIUC it suggests that we inform users of both origins. Besides, the current spec has stronger wording. Is the proposed change intentional?

Should the top frame have full control of which embedded iframe is allowed to send SMS?

e.g. shop.com embeds two iframes payment.com and ads.com. The intent is to allow payment.com to send SMSes and complete the verification flow. But can a compromised ads.com do the same? If so, this may lead to some attack vector discussed here

I understand that this spec should focus on the format and delivery-mechanism-agnostic. Hopefully the questions above are not out of scope.