- From: mpeng-okta via GitHub <sysbot+gh@w3.org>
- Date: Tue, 01 Dec 2020 00:22:36 +0000
- To: public-webauthn@w3.org
Yeah, that's a great point w.r.t. the RP ID scoping. In this particular case, I believe the customer tenants might have region-specific portals e.g. us-west.domain.com, us-east.domain.com (which they would want to scope). However, from an RP perspective, it would also be useful to implement more configurable RP ID matching in some cases as you mentioned, so that those customers that would want interoperability among domains would get their use case satisfied as well. And ah got it, yeah it'd make more sense for the endpoint's page where the WebAuthn browser API is called to do the entire auth, then pass on an authorization token when done (hence it'd make more sense for the initial page to be `auth.d.c`, which performs all the validation then passes the token to `sub.d.c`). In this case, the customer setup is such that the initial `sub.d.c` page has no access to the RP validations, and the final `auth.d.c` endpoint is the API-only RP auth endpoint which performs all the verification. So the developer customer ends up having the `auth.d.c` domain do all the actual RP validations and returning the relevant API response to the initial portal page of `sub.d.c` via a secure channel, and having the WebAuthn browser UI interactions on `sub.d.c`. Thanks so much for the clarifications and helpful discussion! Really appreciate it. -- GitHub Notification of comment by mpeng-okta Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1372#issuecomment-736135118 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 1 December 2020 00:22:38 UTC