- From: =JeffH via GitHub <sysbot+gh@w3.org>
- Date: Wed, 03 Nov 2021 16:08:19 +0000
- To: public-webauthn@w3.org
> ... the proposal doesn't change that in the web-layer API. Agreed. the RP just needs to explicitly set the [RP ID](https://w3c.github.io/webauthn/#dom-publickeycredentialrpentity-id) rather than let the client platform set it ambiently. > ... that means that the RP will need to verify the response [`rpIdHash`](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#rpidhash) against `SHA256(prefix + rpId)` instead of the usual `SHA256(rpId)`. That doesn't seem to me like a big issue, since the RP already needs special logic to process an SPC response anyway. But it does mean that platform authenticators must necessarily work in the same way ... Agreed. AFAICT authenticators only do comparisons on RP ID strings and the hashing you note. Though, authnrs with displays may show RP IDs to users eg during authn ceremonies, and there's also the "credential management" (list creds, etc.) displaying of credentials' RP IDs. So there's some risk of user confusion? A detail level consideration would be whether to have the proposed "spc prefix" contain the delimiter chars "://", because this prefix would be using arguably precious space at the beginning of the RP ID string. It begs the question of whether the resultant `prefix + rpId` **_needs_** to syntactically be a serialized origin. If not, we need some delimiter composed of char(s) that are not legal in a "valid domain string", perhaps simply ":" ...? -- GitHub Notification of comment by equalsJeffH Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1667#issuecomment-959581886 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 3 November 2021 16:08:21 UTC