- From: stephen via GitHub <sysbot+gh@w3.org>
- Date: Mon, 05 Jun 2023 21:45:03 +0000
- To: public-webauthn@w3.org
> I don't know that this would achieve the desired effect. The options could be intercepted by malicious code before the call to `.get()` and `asCryptoKey` could then be flipped to `false` without the RP knowing any better. Then at that point this protection is bypassed and we're back to where we are now :( aha, fair point - i suppose in the case where there's malicious code in the js context, it's pretty much game over. It might be useful for the "avoid bugs" case in not inadvertently spilling the bytes somewhere? that seems about as worthwhile (or not) as having the `extractable` flag in webcrypto perhaps? > (The hash prefix in the PRF extension was designed to be able to meet needs like this. I.e. opaque keys could use a different prefix to ensure domain separation. I don't think the Chromium team has time to look into this sort of thing for quite a while, but PRF was designed to make it possible to do.) sorry - I didn't quite understand this. could you say more about what this means? I didn't see mention of this in the prf extension section of the draft. -- GitHub Notification of comment by stephen Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1895#issuecomment-1577516038 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 5 June 2023 21:45:05 UTC