- From: Firstyear via GitHub <sysbot+gh@w3.org>
- Date: Thu, 03 Jun 2021 05:13:54 +0000
- To: public-webauthn@w3.org
> Of course if the parameters are altered before they reach the call into the client API then the result may be different, I don't think we should have to point that out. The RP operations also contain an explicit step for verifying the UV flag of the response. I think we need to point that out. There has already been a CVE https://nvd.nist.gov/vuln/detail/CVE-2020-8236 from this, AzureAD was affected and has resolved it, and I have successfully acquired bug bounties from IDM platforms for reporting this. It can hardly be question that Microsoft hires probably some of the worlds best developers and security reviewers and *they messed this up*. This is why I think it needs to be much much more explicit about how and what there parameters represent today > > As for the [`authenticatorAttachment`](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#dom-authenticatorselectioncriteria-authenticatorattachment) parameter, I agree we should make it clearer that the actual outcome might be determined using [`getTransports()`](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#dom-authenticatorattestationresponse-gettransports). The [`ResidentKeyRequirement`](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#enumdef-residentkeyrequirement) description similarly points to the [`credProps` extension](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#credprops) for checking whether the new credential ended up discoverable. Yes, credprops certainly helps in that case I agree. :) -- GitHub Notification of comment by Firstyear Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1618#issuecomment-853568494 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 3 June 2021 05:14:41 UTC