Re: [webauthn] Clarify 127.0.0.1 in spec (#1204)

>That's true, but I must be misunderstanding you. The original wording was “all domain names that resolve to 127.0.0.1” but I can edit a file here and make foo.google.com resolve to 127.0.0.1, but I can't see that it helps anything if that causes the RP ID for https://foo.google.com to be localhost.

Let's go with this example.  Assume that there is a web page hosted at 127.0.0.1 and it serves up a self-signed cert with foo.google.com.  I assume the effective domain will be google.com, and even though some browsers may reject such a connection - there is nothing in the Webauthn spec or even the SecureContext spec that specifically disallows use of the Webauthn API from a caller in such a webpage.

Now assume that the authenticator is CTAP-enabled and has already created a credential for google.com based on a previous session with a Google server presenting a valid cert.   if the client passes for instance a getAssertion command (https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-client-to-authenticator-protocol-v2.0-id-20180227.html#authenticatorGetAssertion), it seems that the rpid argument for this example will be google.com (even though the webpage was served up from the loopback address) and there is nothing in the CTAP spec as far as I can tell would prevent the authenticator from using the google.com credential to create an assertion for this foo.google.com webpage.  If the rpid was instead localhost fthen the google.com credential won't be available for use by the webpage in this example.

If the above is actually not possible, please point me to the exact parts of the Webauthn specification that prevent this situation from occuring.

 

-- 
GitHub Notification of comment by gmandyam
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1204#issuecomment-489818382 using your GitHub account

Received on Monday, 6 May 2019 23:03:43 UTC