- From: Emil Lundberg via GitHub <sysbot+gh@w3.org>
- Date: Thu, 26 Nov 2020 15:27:39 +0000
- To: public-webauthn@w3.org
@mpeng-okta It will depend on the implementation details. It is certainly possible for `auth.domain.com` to verify authentication assertions generated for `sub.domain.com`, and accept `sub.domain.com` as a "matching" domain, but one needs to take care to do that securely. For example, in the case you describe it would presumably be `sub.d(omain).c(om)` that generated the `challenge` parameter. `auth.d(omain).c(om)` needs to know the expected challenge in order to verify it; if `auth.d.c` receives the challenge along with the assertion from the client in the redirection, then this opens up for attacks where an attacker could replay a previously captured challenge and assertion. In order to preserve the anti-replay feature, `auth.d.c` would have to receive that challenge from `sub.d.c` via some other, trusted channel, which might defeat some of the advantages of the redirection flow. However, I suspect you might be better off having `sub.d.c` perform the whole authentication ceremony and verify the assertion, and then return some authorization ticket (for example, an OAuth2 PKCE authorization code) instead of returning the raw WebAuthn assertion. (And it would probably be `sub.d.c` that redirects to `auth.d.c`, which performs the WebAuthn ceremony and then redirects back to `sub.d.c` with the authorization ticket.) -- GitHub Notification of comment by emlun Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1372#issuecomment-734360039 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 26 November 2020 15:27:41 UTC