- From: Arnar Birgisson via GitHub <sysbot+gh@w3.org>
- Date: Wed, 24 Jan 2024 21:13:36 +0000
- To: public-webauthn@w3.org
Let me verify this with Android experts, but my interpretation is that each security property can be either enforced in software or in TEE, and they can combine independently. E.g. KM_ORIGIN_GENERATED in the teeEnforced would mean the key was generated in the TEE but enforcing that the key is only used for sign ops (KM_PURPOSE_SIGN) could still be enforced by software, and therefore that property would appear in the softwareEnforced field. I don't actually know if that's a valid combination, it at least seems odd. But assuming it is valid then I think the spec is correct. In essence: 1. If an RP cares about TEE enforcement, check only the teeEnforced list. 2. If an RP is ok with software enforcement, check each property appears on /either/ softwareEnforced or teeEnforced, individually. I.e. there's no reason for an RP that accepts software enforcement to reject a credential where one of these is actually TEE enforced. I'll double check if this is actually a valid scenario. -- GitHub Notification of comment by arnar Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1980#issuecomment-1908924638 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 24 January 2024 21:13:40 UTC