- From: mpeng-okta via GitHub <sysbot+gh@w3.org>
- Date: Wed, 25 Nov 2020 23:14:32 +0000
- To: public-webauthn@w3.org
Hi @equalsJeffH and @emlun, as an RP developer, had some question regarding the interpretation of the spec: Section 7.1.5: > Verify that the value of C.origin matches the Relying Party's origin. Section 7.1.9: > Verify that the value of C.origin matches the Relying Party's origin. There's a use case where a user performs the WebAuthn registration or verification at `sub.domain.com`, some portal page, then there are some redirects until the resultant WebAuthn data hits `auth.domain.com`. This is where the actual RP verification happens, and at this point, the origin validation would fail, because the RP expects an origin of auth.domain.com from the request context, whereas the actual WebAuthn request was performed at `sub.domain.com`. My question is this: does the spec indicate that the RP's origin at the `auth.domain.com` is _required_ to be the sole "true" origin, or can one interpret "matches the Relying Party's origin" as allowing for some admin configuration of acceptable RP origins against which to match? In other words, can the RP specifically configure `sub.domain.com`, `a.domain.com`, `b.domain.com`, etc to be matches for "its" origin, and thereby accept challenges against these origins, despite the final endpoint being `auth.domain.com`? It doesn't appear to be the "optimal" implementation, but given that there's some customer framework set up this way, I was wondering whether this implementation falls within acceptable bounds. My original reading of the spec led me to believe that there's a 1:1 correspondence between RP and origin, but it seems possible that this is outside of the requirements scope of the spec, and the implementation of the "matching" is left to the RP. Thank you so much for your time! -- GitHub Notification of comment by mpeng-okta Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1372#issuecomment-733986288 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 25 November 2020 23:14:34 UTC