Re: [webauthn] Client-generated challenges

No, there's nothing in the spec that technically requires the trust boundary to exactly include only the server. I don't think I fully understand your use case, but the general idea is that whatever runs on the client side is controlled by the user, and any security checks in that code can therefore be bypassed.

It doesn't quite sound like that's what you're describing, though. Did I get this right?

1. Alice logs in and proves she's an admin (e.g. by signing a challenge generated on the server, which is then verified on the server).
2. Alice uses client side script to generate a JWT.
3. Client side script uses Alice's public key credential to sign the JWT.
4. JWT with Alice's admin signature is sent to ordinary user Bob.
5. Bob sends signed JWT to server, and receives a perk.

If that's what you're describing, I _think_ that sounds reasonable enough. In this case it seems plausible to expand the trust boundary to include Alice's client side script, because she's an admin who's trusted to not mess things up.

It might still not be a good idea, though, as it would make auditing and such harder. If Alice were to _become_ evil, that would be harder to detect and investigate than if these things were done server side. Be sure to have a clear and well thought out threat model so you know what you're doing if you do want to go that route.

-- 
GitHub Notification of comment by emlun
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/902#issuecomment-388223929 using your GitHub account

Received on Friday, 11 May 2018 00:23:52 UTC