Re: [webauthn] Adding a choice for RP to express preferences for attestation types

In enterprise space, details about credential matters a lot including can the key be exported or not, therefore we need to know software vs hardware and react to issues like broken keys. If a customer needs to comply with some legal requirement to keep a key in hardware, we have to know details about authenticator. If a customer needs to have effective revocation story, we have to know details about it. Alerting users to throw away tokens has even less chance of working as asking them to keep their software up to date. FIDO metadata service is supposed to have information about FIDO tokens and manage them. If it is missing something, lets make it better. And FIDO should be THE ROOT that gives attestation certificate based on devices which passes certification process in FIDO. 

We also need to see full proposal of how privacy CA model works so that we can figure out how we can implement that in our platform if Google RP is being used in our Edge platform. Questions like who is standing up these privacy CA's? Does each platform supposed to stand up their own privacy CA or does FIDO will have a centralized privacy CA? Will platforms be able to call each other's CA's if each one is standing up their own. How about less powerful platforms in that case? Does RP has a say which privacy CA's they trust and can they influence that from the WebAuthN API level? What are the SLA for these CA's on revocation? What is the vulnerability disclosure process?  There are many questions which we don't have clear answer to. 

>From the RP's perspective, we want to enable the same experience across all the platforms. 
>From the platform's perspective, we want to enable same experience for all the RP's. 

All this gives me a feeling that we are lacking a solid proposal as of now and it needs much more thought. Anyway, if we believe we need this right now, I propose the following to enable the privacy CA path for the platforms as well as authenticators where we can discuss its characteristics at some later stage and also support both the deployment scenarios.

WebAuthN Credential Create needs to have the optional privacy enum option `PrivacyPreference` with following semantics: 

- `None`: Platform decides the default behavior

- `Require`: Platform must support privacy CA. If platform does not support privacy CA, makeCredential will fail. Platform needs to pass an additional option to CTAP authenticatorMakeCredential (lets call it as a Boolean option `enablePrivacy` with default behavior false) to enable privacy CA from the authenticator(for example, hide AAGUID in the attestation data by filling it with all zeros)

- `Disable`: Platform will not apply privacy CA semantics to this create credential call. Platform will not send `enablePrivacy` to the authenticator and authenticator will not hide any information like AAGUID for example. Platform will return authenticator Attestation information to RP.


-- 
GitHub Notification of comment by akshayku
Please view or discuss this issue at https://github.com/w3c/webauthn/pull/636#issuecomment-337391010 using your GitHub account

Received on Tuesday, 17 October 2017 22:17:50 UTC