- From: Arnar Birgisson via GitHub <sysbot+gh@w3.org>
- Date: Fri, 17 Aug 2018 18:09:15 +0000
- To: public-webauthn@w3.org
Thank you for these observations. Which authorization list to use depends on what the RP wants. If they are satisified with software enforcment the appropriate thing is to consider the union of the two lists. If they require TEE enforcement they should only check the teeEnforced list. It may even be appropriate to look at different lists for the different authorizations. For example an RP might want the key to originate from a TEE, and thus should check that .origin = KM_ORIGIN_GENERATED is on the teeEnforced list - but at the same time be satisified that the "allApplications" is absent from both list. I'm not sure the best thing is to spell this out in the spec, rather than refer the reader to the Android SafetyNet documentation. We can add language that makes it clear that the RP should pick a combination of authorizationLists that fits their requirement w.r.t. TEE enforcement. What do folks think? KM_TAG_GENERATED has indeed changed to KM_ORIGIN_GENERATED. Perhaps it's also better here to say something like "If desired, verify that the key material originated from the device by verifying that the .origin field in the authorization list is KM_ORIGIN_GENERATED. If software keys are acceptable, use a combination of softwareEnforced and teeEnforced, if a key generated in a TEE is required use only teeEnforced." If that sounds reasonable I can type this in a PR. -- GitHub Notification of comment by arnar Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1022#issuecomment-413946202 using your GitHub account
Received on Friday, 17 August 2018 18:09:17 UTC