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

> If “FIDO” is the thing-in-the-enum, is the implementer required to support BLE, USB, and NFC protocols in order to claim compliance with what is in the enum, say? Should the thing-in-the-enum be versioned?

Who is "the implementer" here? If you mean the browser implementer, then no. The fact that you a credential with this enum value means that the browser implementer has support for at least one of these ways of connecting to a FIDO credential, that's all. For example, my phone has no usable USB port, so it makes no sense to require it to implement support for the FIDO USB device protocol.

If you mean the FIDO device implementer, then also the answer is no. It's extremely rare that a single device would support all the connection types.

Should the enum be versioned - I think this is essentially what the "growing enum" school of thought would posit. That for example if we ended up with a new version like say FIDO v17, then we would add an enum value for "FIDOv17". I wonder if this is the essential conflict here - a "fixed enum" school of thought that says we define one generic enum value, and room for all sorts of devices to share that, and a "growing enum" school of thought that says we implement an extensible protocol with the enum as a versioning mechanism, and if an entirely new device class shows up maybe it's just a new version.

> One thing that might help would be to suggest another somewhat-concrete example of what other item(s) might appear in this enum.

Let me suggest two extreme scenarios to explore this space. I'm sure others can think of more.

Let's say it turns out that the way we combine the fields in the assertion is cryptographically unsound (we believe it is sound, but cryptography has a way of revealing new issues like this over time) and the only way to fix it is to revise the signature format. Would we expand the enum?

Let's say that someone comes up with a radically new type of token which has a very different and distinctive UX which requires different user guidance from the RP, while in the end producing assertion signatures compatible with our current spec. Would we expand the enum?

-----Original Message-----
From: John Kemp [mailto:stable.pseudonym@gmail.com] 
Sent: Thursday, March 10, 2016 10:03 AM
To: Vijay Bharadwaj <vijaybh@microsoft.com>
Cc: Richard Barnes <rbarnes@mozilla.com>; Anthony Nadalin <tonynad@microsoft.com>; Hodges, Jeff <jeff.hodges@paypal.com>; W3C WebAuthn WG <public-webauthn@w3.org>
Subject: Re: wrt all those "FIDO" terms, e.g. "FIDO Credentials" - new names?

Some potentially clarifying questions:

> On Mar 10, 2016, at 11:46 AM, Vijay Bharadwaj <vijaybh@microsoft.com> wrote:
> 
> 

[…]

> -          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.

If “FIDO” is the thing-in-the-enum, is the implementer required to support BLE, USB, and NFC protocols in order to claim compliance with what is in the enum, say? Should the thing-in-the-enum be versioned?
 
>  
> 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.
>  
> 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” and those implementing Example Alliance protocols have CredentialType “Example”)?

One thing that might help would be to suggest another somewhat-concrete example of what other item(s) might appear in this enum. 

- johnk

> 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?
>  
>  
> From: Richard Barnes [mailto:rbarnes@mozilla.com] 
> Sent: Thursday, March 10, 2016 6:15 AM
> To: Vijay Bharadwaj <vijaybh@microsoft.com>
> Cc: Anthony Nadalin <tonynad@microsoft.com>; Hodges, Jeff <jeff.hodges@paypal.com>; W3C WebAuthn WG <public-webauthn@w3.org>
> Subject: Re: wrt all those "FIDO" terms, e.g. "FIDO Credentials" - new names?
>  
>  
>  
> On Wed, Mar 9, 2016 at 6:40 PM, Vijay Bharadwaj <vijaybh@microsoft.com> wrote:
> Tony beat me to this one.
>  
> This seems to add unnecessary cognitive overhead for web developers. They have to just know that if they want to support those flashy dongles with the FIDO logo, they need to use “ScopedSignature” (having a CredentialType enum value include Credential in its name seems like a redundant bit of redundancy) in their code. Moreover, using “FIDO” as an enum value in no way prevents the existence of other possible enum values. The API names and namespaces remain generic after all.
>  
> That's a very myopic view.  Look, I'm sure that calling WebRTC the Hangouts API would appeared to reduce developer overhead in the early days of that spec, when Hangouts was the only thing using it.  But as Felipe says, not all that many developers have heard about FIDO today, and to be honest, I hope this spec outlives FIDO.  I mean no ill will toward the FIDO Alliance, but honestly in this space, device standards come and go; the Web abides. 
>  
> --Richard
> 
>  
>  
> From: Anthony Nadalin [mailto:tonynad@microsoft.com] 
> Sent: Wednesday, March 09, 2016 3:06 PM
> To: Richard Barnes <rbarnes@mozilla.com>; Hodges, Jeff <jeff.hodges@paypal.com>
> Cc: W3C WebAuthn WG <public-webauthn@w3.org>
> Subject: RE: wrt all those "FIDO" terms, e.g. "FIDO Credentials" - new names?
>  
> I’m getting a little worried that we are now in meaningless territory as “FIDO” had a specific meaning the “ScopedSignatureCredentails” can mean anything. The use of FIDO is just like the use of RSA here.
>  
> From: Richard Barnes [mailto:rbarnes@mozilla.com] 
> Sent: Wednesday, March 9, 2016 1:30 PM
> To: Hodges, Jeff <jeff.hodges@paypal.com>
> Cc: W3C WebAuthn WG <public-webauthn@w3.org>
> Subject: Re: wrt all those "FIDO" terms, e.g. "FIDO Credentials" - new names?
>  
>  
>  
> On Wed, Mar 9, 2016 at 4:28 PM, Hodges, Jeff <jeff.hodges@paypal.com> wrote:
> On 3/9/16, 1:20 PM, "Richard Barnes" <rbarnes@mozilla.com> wrote:
>  
> """
> API Features in scope are: (1) Requesting generation of an asymmetric key pair within a specific scope (e.g., an origin); (2) Proving that the browser has possession of a specific private key, where the proof can only be done within the scope of the key pair. In other words, authentication should obey the same origin policy. 
> """
> 
> So this is a credential that provides authentication based on proof of possession of a signing key (i.e., a signature), where that signature is limited to some scope via the signing protocol we will define.
> 
> Could people live with "ScopedSignatureCredential"?
>  
> so you are suggesting..
>  
> enum CredentialType { 
>     "ScopedSignatureCredential" 
> }; 
> .. yes?
> Precisely.
> 
>  
> sure, I can live with that. 
>  
> =JeffH

Received on Thursday, 10 March 2016 18:27:49 UTC