- From: Matthew Miller via GitHub <sysbot+gh@w3.org>
- Date: Tue, 06 Apr 2021 15:42:36 +0000
- To: public-webauthn@w3.org
> By contrast, @Mikescops's use case of a browser extension authenticating itself to a remote server (for example, to download an encrypted vault file) is a different matter and is compatible with challenge-response authentication. It appears I've misunderstood @Mikescops's use case, I inferred that RP was running locally too. Understanding now that their RP is indeed remote, I still see the issue they're having to deal with because RP ID definition is vague about clients running in website-adjacent contexts. > WebAuthn couldn't be used for local authentication like this because it is a challenge-response authentication method, and challenge-response authentication only works when client and server are separate. Otherwise the user can bypass the authentication by simply using a different client without the authentication check. In my defense I never said it would be a _good_ mechanism for login if the RP was running locally. I agree that WebAuthn running locally would be as effective a login mechanism as a PIN one would enter. Unless the app takes additional steps to encrypt the data locally it's at best a way to keep unmotivated attackers out of local data. > But then this differs from the initial topic of this issue which was about allowing cross-domain use between a.c and b.c. Shall we create a different thread? @Mikescops: I don't see why not, feel free to make a new issue so this thread can remain about cross-subdomain use. -- GitHub Notification of comment by MasterKale Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1372#issuecomment-814224064 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 6 April 2021 15:42:37 UTC