Adding flexibility in client origin scheme validation to align with real world implementations

[abergs]

I suggest adding a little bit of flexibility to the requirements on validating the scheme to be https. This is in response to the real world implementation by clients, where clients (browsers, chrome) allow webauthn on localhost running on the http-scheme. We've been receiving negative feedback for following this part of the spec. I wanted to suggest adding just a little bit of flexibility here, hopefully without opening a can of DNS worms.

I might be sticking my shin out here, since I know the topic of localhost has been brought up in previous calls with varying (dis)-agreement. E.g issue #1204 morphed into a discussion on DNS.

Either I'm misinterpreting the current writing, but to me it's quite clear about not allowing http in any case.

Original:

Updated:

---

Preview | Diff

[abergs]

@MasterKale any thoughts? I don't wanna hog the meeting minutes on Wednesday, if this is dumb I'd rather close it before then.

edit: ipr failed because my accounts didn't line up. It's been fixed.

[emlun]

Seems fair to me.

[MasterKale]

This seems fine to me. The spec mentions secure contexts a couple of times but it's far from obvious that http://localhost is one especially if all you're going off of is WHATWG.

I suggest we also specifically call out here that http://localhost addresses are valid. Let's include a localhost example here too? And maybe a mention of an address like http://localhost:8000 being valid too because many JS frameworks will start local dev servers on a different port than 80.

[timcappalli]

makes sense to me

[abergs]

@MasterKale I agree and even thought about adding an example too, but didn't want to be too specific in order to open the door for more question.

I'll add second PR with a suggested example so that it can be independently accepted/rejected.

[nsatragno]

Drive-by review

[abergs]

Incorporated @nsatragno feedback, it now spells out the behaviour:

[nsatragno]

Approved, thank you!

[emlun]

Thanks!

[abergs]

@emlun I tried to keep this PR focused to this section of the spec. I noticed that there are more usages of [=host=] elsewhere. I can adress those in a separate PR if [=origin/host=] is more suitable(?)

[barryp]

Is this going to cover the case of having names in a /etc/hosts file like

127.0.0.1 foo.localhost
127.0.0.1 bar.localhost 

and then trying to access http://foo.localhost or http://bar.localhost? I'm doing this on my development laptop with several sites.

Seems like those are considered Secure Contexts elsewhere.

[abergs]

@barryp While I sympathise with your use case, I'm desperately trying to stay away from #1204. I'd be happy to get this in to get a 80% win, and then hash out the remaining 20% in a separate issue/pr if that makes sense.

[emlun]

@emlun I tried to keep this PR focused to this section of the spec. I noticed that there are more usages of [=host=] elsewhere. I can adress those in a separate PR if [=origin/host=] is more suitable(?)

Sorry for the delayed response - yeah, I don't think we need to change any other occurrences. (Probably, I might take a look into that later)