webauthn
webauthn copied to clipboard
w3c
Include enterpriseAttestation in getClientClientCapabilities
- Adds
enterpriseAttestationto getClientClientCapabilities enum - Adds blurb to "enterprise" definition that clients should include it
Resolves #1742
@msft-bob looks like you're not in the repo so I can't assign review to you, but flagging for your feedback via comment
This probably needs to take into account not only whether the client can support enterprise attestation, but also whether enterprise attestation is allowed for the calling RP.
@emlun the intent was to only convey whether the WebAuthn client supported it, not whether it was allowed for a given origin/RP.
Ah, ok. In that case it's probably worth mentioning in the {{ClientCapability/enterpriseAttestation}} definition that the presence of this capability is no guarantee that the client's/authenticator's policy allows EA for the calling RP.
Ah, ok. In that case it's probably worth mentioning in the {{ClientCapability/enterpriseAttestation}} definition that the presence of this capability is no guarantee that the client's/authenticator's policy allows EA for the calling RP.
@emlun addressed in https://github.com/w3c/webauthn/pull/2051/commits/51b4b409f5605f3d1ff6fd77baa4e542ef52e782
The type error if an attestation type is not supported should not be a reason to merge this. Browsers should not error out on unknown values to begin with, and we should not patch non compliant behaviour with more feature detection.
However, when an RP requires Enterprise Attestation, it probably doesn't make any sense to continue the ceremony when it has no chance to succeed -- so I can see value in this capability. My only concern is there will be a gap until we get the browsers updated where EA will be supported, but this capability will not. Are we risking those RPs assuming EA is not supported when it is during that gap?
