- From: Emil Lundberg via GitHub <sysbot+gh@w3.org>
- Date: Mon, 30 Nov 2020 23:35:20 +0000
- To: public-webauthn@w3.org
> This use case is basically where developer users have an existing framework hosting a sign-on page at some set of `sub1.d.c`, `sub2.d.c`, etc domains, so the approach idea is to receive all the WebAuthn config values (e.g. user verification, authenticator attachment, allowed credentials, and so on) and challenge values from a central `auth.d.c` domain, then pass the resulting outputs of the WebAuthn ceremony to a common `auth.d.c` domain for the actual ultimate auth. Note that in this use case, you will probably have to set the RP ID to just `domain.com`, without the more specific subdomain. Otherwise, `sub1.domain.com` and `sub2.domain.com` will not be able to exercise each others' credentials, so the user would have to register once per subdomain (and `auth.d.c` would need access to the user's credential public keys from each sibling domain). Whereas with `rpId: "domain.com"`, all three subdomains could exercise the same credential which the user needs to register only once. >@emlun with respect to your last comment [...] No, I just meant that the example names seemed a bit backward. It seems more likely that `auth.d.c` would be the one performing the authentication instead of consuming the authentication result. You can just ignore the final parenthetical in my previous comment, it doesn't really add anything new. -- GitHub Notification of comment by emlun Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1372#issuecomment-736119395 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 30 November 2020 23:35:22 UTC