Web IDL support 2/N: drop HMAC from WebAuthn ops #166
Conversation
AlfioEmanueleFresta
force-pushed
the
json-prf-only
branch
from
012daa7 to
22cfada
Compare
AlfioEmanueleFresta
force-pushed
the
json-prf-only
branch
from
22cfada to
fbeed1c
Compare
AlfioEmanueleFresta
force-pushed
the
json-prf-only
branch
from
fbeed1c to
e57fbc0
Compare
msirringhaus
left a comment
msirringhaus
left a comment
There was a problem hiding this comment.
I'd be fine with this as is. I just have the question, if we should cut off HMAC as drastically.
| Some(ext) => match &ext.prf { | ||
| Some(prf_json) => Some(PrfInput::try_from(prf_json.clone())?), | ||
| None => None, | ||
| }, |
There was a problem hiding this comment.
I wonder if we should only do this change here and keep HMAC available for the Rust-API, which isn't a strict webauthn-compliant interface as opposed to the JSON-interface?
I've seen some questions of potential users of this extension floating around, but I'm not sure if they have changed by now to PRF.
There was a problem hiding this comment.
I'm OK with the changes too, so I'm going to go ahead and merge.
I see that the Ctap2GetAssertion model still has HmacOrPrf; was there another part of the Rust-API that you think we should preserve?
There was a problem hiding this comment.
I was thinking about leaving the option in GetAssertionRequestExtensions, as that is what a user would interact with, if they do not use JSON. So the Rust API might be a bit more 'powerful' in that sense, and the JSON-API more strict regarding webauthn-spec.
3 participants
See comment: #138 (comment)