- From: Ki-Eun Shin via GitHub <sysbot+gh@w3.org>
- Date: Sat, 26 Aug 2023 02:54:46 +0000
- To: public-webauthn@w3.org
@nicksteele I'm happy to create a draft PR and well noted. @ve7jtb As a RP, it is better not to return any attestation (`attestationObject`) if the RP does not explicitly request (does not set any attestation value in the assertion options). If we return attestationObject (with `none` attestation statement), some of current RP implementations would be broken since we've already introduced sort of helper methods like `toJSON()` which might be directly used to submit the response to RP server API. But, if the RP does have strict validation logic for the inputs, it would return bad request or similar errors. So, for RPs, there are following cases for the assertion options. 1. Does not set any value for `attestation`: meaning is that I'm not interested in attestation and please do not return `attestationObject`. 2. Set `attestation` as `none`: meaning is that I don't have any interests to verify the attestation, but if the authenticator could return `self` attestation (self-signed), it would be better than nothing. 3. Set `attestation` as `indirect`, `direct`, or `enterprise`: meaning is that at least RP would like to verify attestation, give me attestation if supported For the first case, the `attestationObject` must not be included in the response. For the second and third cases, the `attestationObject` might be included if the client and authenticator supports attestation in assertions features. I'm thinking that CTAP needs to have a way to support such cases. -- GitHub Notification of comment by Kieun Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1941#issuecomment-1694131674 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 26 August 2023 02:54:49 UTC