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

On Thu, Mar 10, 2016 at 11:46 AM, Vijay Bharadwaj <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.
>
>
>
> 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”)? I suspect that the strong disagreement on
> naming comes from some people being on one side of this argument vs. the
> other.
>

Thanks for the good refocus.

I would note that this is slightly more than an enum -- the values of the
enum label interfaces that one uses to create and manage credentials.

Personally my expectation would be that the values in the CredentialType
enum would correspond to the functional / security properties provided by
the credential.  PasswordCredential objects provide a way to manage
passwords (with the concomitant security risks), and FederatedCredential
objects provide a way to manage federated logins.  "FIDO" doesn't tell me
anything about what this thing is, unless I unravel a layer of indirection
to figure it out.  And even then, it's over-specific, since (for example)
some browsers might have a built-in tokens that doesn't follow the FIDO
protocols at all but still expose the same functional interface.

Note that as a corollary to the above, I would expect for this WG to
produce exactly one CredentialType.  We are chartered to create an API with
a specific set of functional properties, so we should create one type of
credential to expose them.

--Richard



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