Re: wrt all those "FIDO" terms, e.g. "FIDO Credentials" - new names?

thanks Vijay, this is a useful approach, seems to me, some thoughts below..

On 3/10/16, 8:46 AM, "Vijay Bharadwaj" <vijaybh@microsoft.com<mailto:vijaybh@microsoft.com>> wrote:
This seems like a bit of a strawman argument. Nobody is proposing to name the API something non-generic.

It occurs to me that we might have some diversity of views on what exactly the problem is, and maybe some of the nuance got lost in the noise. So I'm going to try and go back to the beginning. I'm going to avoid making any suggestions in this email, and only describe the problem. My goal here is to understand if there is a deeper disagreement, and to try to get to a shared understanding of that.


-          We have a spec that is intended to support a large number of authenticators each of which has a certain property that they cryptographically convey the human user's intent to a remote relying party over the web.

-          We understand that this API will need to talk to devices with the help of the platform, and the method of connection of those devices to the platform is deliberately not specified here.

-          The FIDO Alliance represents one way in which such devices can connect to the platform, by specifying things like BLE, USB and NFC protocols that convey the API primitives to a device.

We have at least three things to name:

-          The API itself - there seems to be consensus that a generic name is appropriate here, and that was my original proposal as well.

-          The namespace in which the API exists - again, generic is good.

-          The enum within the API which designates the type of a specific credential - this is where the controversy is.

yep, wrt the latter.


 Perhaps one fundamental question to ask is how people see this enum evolving. Do you think the enum should contain a small number of generic items (e.g. all authenticators complying with this spec have CredentialType "WebAuthN") or do you think of this enum as a thing which grows over time to accommodate for example new device standards with the same functional properties (e.g. things implementing FIDO device protocols have CredentialType "FIDO"

though are we not trying to name the "type of specific credential" as you noted above, which to me to be orthogonal to the "FIDO device protocols" (an authenticator may or may not be incorporated within a "platform" via those protocols) ?

at our level of abstraction in this wg, is it not appropriate to define  the "type of credential" as that  which takes a clientDataHash [1] as input and produces both a authenticatorData and a "raw signature" as output per [2] ?

I note that the  authenticatorData  incorporates information regarding the user, and so a definition as above would seem to accomodate Sam's observations and concerns (yes?)


and those implementing Example Alliance protocols have CredentialType "Example")? I suspect that the strong disagreement on naming comes from some people being on one side of this argument vs. the other.

Does that sound like a reasonable characterization of the issue? If so, maybe we should reach consensus on the underlying issue before diving into naming again?

Yes, i agree that coming to consensus  on the definition of the credential type ought to be accomplished before trying to agree on its name.

[1] https://www.w3.org/Submission/2015/SUBM-fido-signature-format-20151120/#client-data

[2] https://www.w3.org/Submission/2015/SUBM-fido-signature-format-20151120/#authenticator-signature


HTH,

=JeffH