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

>Presumably, on my machine here, I ought to be able to now run a webauthn-wielding webapp on localhost for testing or whatever purposes (tho it does require jumping thru various hoops, and I haven't tested the running a webauthn-wielding webapp as yet). Presumably, I could add further hostnames to /etc/hosts that resolve to 127.0.0.1 and create self-signed certs (or one cert with multiple dnsname subjectAlternativeName entries) for them and (I'm guessing) that'd work.

Yes, but will the Webauthn caller be assigned an RP ID = localhost for all of the domain names that resolve to 127.0.0.1?  

Note that the CTAP spec normatively refers to Webauthn's definiton of RP ID:  https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-client-to-authenticator-protocol-v2.0-id-20180227.html#authenticatorMakeCredential. 

Note also that long-standing FIDO Privacy Principles (https://fidoalliance.org/whitepaper-on-privacy-principles/) state:  "Other technical safeguards within the FIDO specifications include that a key issued to a particular website can only be exercised in a web browser by that website, amplifying the strong boundary between different sites. This requirement renders useless the theft of a public key for the purposes of phishing from another origin, and also prevents multiple colluding sites from using an Authenticator to strongly verify and correlate a user’s identity as he or she browses the Web."

So it seems that the current CTAP normative reference to the Webauthn definition of RP ID is problematic if there is a way for a webpage hosted at the loopback address to be able to use an RP ID corresponding to a domain that is not associated with that address.  There are certainly legitimate reasons to set up test pages on the loopback address, but such pages (if they are going to be allowed to invoke Webauthn) should not result in privacy (linkability) violations through the CTAP protocol.

One solution is could be to augment the RP ID definition in the CTAP spec and create appropriate requirements for RP ID in any client beyond what Webauthn calls for.  If so, then you are right - there's not anything to add to the Webauthn spec.  It is the CTAP spec where this needs to be addressed.

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

Received on Friday, 17 May 2019 00:18:47 UTC