- From: David Waite via GitHub <sysbot+gh@w3.org>
- Date: Thu, 26 Nov 2020 10:19:03 +0000
- To: public-webauthn@w3.org
@mpeng-okta I assume you know that the RP ID in this sort of scenario would need to be "domain.com" if you want sub, auth, a, b, and so on to have visibility with the same set of credentials. Speaking with a level of authority which is *quite* risky in this particular forum, multiple relying parties can share RPID values. The services at sub, auth, a, and b in this example are all relying parties with different origins. The verification here is that the value of C.origin must match the origin of your relying party. so a credential request from sub.domain.com must verify the origin in CCD as https://sub.domain.com If auth.domain.com is an API service for handling webauthn which authenticates back-channel communication from sub.domain.com, auth can handle the validation that 'sub' is correct. If communication between sub.domain.com and auth.domain.com happens solely via redirection, then this is much more difficult to do securely. You also could lose potential future security properties, such as stronger phishing resistance through token binding or some other channel binding. However I believe this communication between sub and auth would still be a relying party outsourcing its responsibilities, which is out of scope currently. -- GitHub Notification of comment by dwaite Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1372#issuecomment-734209579 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 10:19:05 UTC