Eliminate duplicate terminology #1648
Comments
|
Initial post prompted by this comment in #1565. |
|
FWIW, we have to be really careful about nuances and not footgunning ourselves (any more than we have already). we can't simply wave a magic wand and auto-edit all those distinct terms to be a more generic term (as seemingly suggested above), it'll break all kinds of things. for example, a public key credential and a public key credential source are in general different things, but it is quite context-dependent, as we attempt to clarify in the first parag of public key credential's definition:
A huge part of the problem (from my perspective) is that we are lazy in our discussions and instead of using fully-qualified terms in discussion (whether verbal or written), folks either drop the qualifications or just invent yet more terms, and then others latch onto that utterance and repeat it, and then >poof< we have yet another term. We've documented some of the more common duplicitous terms but no where near all. The underlying problem is that even though at a high abstract level, as @arshadnoor points out in his #1565 (comment), the abstract WebAuthn/FIDO model is fairly simple, under the hood it is decidedly not simple, regardless of what various folks might think. And the webauthn spec largely concerns specifying the various "under the hood" details such that this simple abstract model can be concretely manifested within complex existing systems. This necessarily involves tons of nuances and we have a multitude of audiences (see 1.1. Specification Roadmap):
IMV, hopefully, the WebAuthn adoption effort can, e.g., craft overview docs for each of those audiences and cherry-pick the necessary terminology from the main webauthn terminology (without necessarily inventing new terms). Not inventing terms is a tough call as we found out in writing How to FIDO where we ended up inventing yet more terms, from the RP developer perspective. Though, those terms are over there in that separate how2fido doc where they belong. |
|
Agreed. I don't expect to fully de-duplicate all of the above terms, but maybe at least reduce the frequency of some of the duplicates and keep them more contained around their definition sites. I think this will impact the Authenticator Taxonomy section most of all, especially since some of those definitions aren't even used outside that section, or only barely. |
Ok, cool. The key is determining are the characteristics of actual "duplicate" terms. The spec is more complex now than it was when issue #358 was originally submitted. I'd have to see in-context examples. Also we explicitly list duplicates in the terminology section (because folks use them often or we are pursposefully drawing equivalence between a long-form and short-form term(s)) and then try to use only one of that array of duplicate terms in the spec (that's the intention anyway). Also a number of the terms you list in the original post are not duplicates per se.
Ok. |
|
Jeff (@equalsJeffH), If we are worried about shooting ourselves in the foot with definitions, I don't think we need worry. I can't imagine doing any worse damage than this referenced text in the specification:
With all due respect to the people behind this specification, this is what happens when we throw out established conventions/terms and invent new ones simply because it is a new specification, created by new people for a new environment. As someone who was first introduced to public-key cryptography in 1992 (PGP), and built at least a dozen PKIs for some of the world's largest companies (including central banks) since then, I am appalled that future generations of technologists are going to have to live with these terms instead of what they are: Public Key Credential: Traditionally known as Public Key Do all the objects referenced by their conventional names contain a Public Key? You bet! But, no one in their right mind would call them all "Public Key" regardless of the context. How on earth did this specification end up naming 4 different objects with the same name just because of the context? I realize the FIDO ecosystem is not PKI - and I'm not trying to make it look like one. But, with the exception of the use of "Digital Certificate" (I might have named an attested public key as "FIDO Key") what was wrong in calling the other objects by what they are traditionally known? |
|
I wasn't around when these terms were chosen, but anyway: Some context here is that WebAuthn is, formally speaking, an extension to the Credential Management spec. That's where the first two terms come from:
Public key credential and public key credential source are simply a specialization of those abstract parent terms. The term gets overloaded because of the many spec audiences. From an RP point of view, the "credential" is the thing that proves the user's identity: the authentication assertion, in combination with its registered public key. But from a user point of view, the "credential" is the thing you use to authenticate: the private key in the authenticator, which CredMan calls a "credential source". "Attested public key" does not appear as a term in the spec; the original of your quote references two separate terms "attested (attestation)" and "credential public key". There is the term attested credential data, which is the name of a specific new data structure. As for "authentication assertion", I don't really know, but if I may speculate... To me, the term "digital signature" carries the sense of applying a "seal of approval" to an independently useful payload, and that the signature will be useful for a long time after it was created. By contrast, an authentication assertion as defined here is a response to a real-time authentication challenge and is typically only useful for the duration of the authentication ceremony. The term also appears in the context of Security Assertion Markup Language (SAML); I don't know if there's a causal relationship, but several members of this working group helped write that spec too. |
|
Hi Emil (@emlun), I understand why the specification has the terms it does. But, my point is: when the industry had 30+ years of history, terminology and literature that documented those concepts/processes extremely well, to have thrown it all out for this specification was not only a disservice to the people who labored to write papers, articles and books explaining these complex topics, but it also denies current and future generations of technical people a basis for recognizing that these are the same concepts. This was a missed opportunity to have made the specification simpler. A digital signature has no lifetime - other than what the RP chooses to assign to it. It can be temporal - as you define - or it can be long-lived. But, it does not change what it is. The reason SAML uses the term "assertion" is because SAML is not an authentication protocol, but a federation one. It cannot claim to authenticate someone using the SAML protocol, but merely assert that the user is who it claims to have authenticated using some other authentication protocol. RPs have to trust the assertion; and if they do, they carry on as if they authenticated the user themselves. Consequently, SAML and all the other federation protocols are third-parties to the authentication process. FIDO, on the other hand, authenticates the user directly. With a digital signature! When the FIDO server responds to the web-application with a "Yea" or a "Nay", it is not asserting as a third-party that it authenticated the user - but is absolute in claiming (as a first party) that it authenticated the user (or not). In any case, I've probably said too much about this, because its unlikely the specification is going to change very much. Thanks for your effort to try to reduce the overloading and confusion. |
Web Authentication authenticates the user with an authentication-protocol-specific message from a piece of hardware which the Relying Party has to trust in order to use for authentication. The Relying party is insulated from knowing how the authenticator did that or what form the authentication took; it is insulated from knowing how private keys are protected and whether things like user verification or user presence detection were done properly. Trust decisions are based on the user opting to use the authentication, on attestations from the vendor that they implemented a certain set of policies or protections and/or by third-party audit. Similarly, trust in federated protocols has been based on user choice for OpenID 1/2, on peer negotiations for typical SAML deployments and by third parties in the case of something like InCommon. That a relying party chose to implement processing logic via a FIDO-certified server does not change that the authentication is coming from outside its security domain, that it needs to make a trust decision in order to process the response. While assertion may not be the best term, I don't see it as an inaccurate one. Digital Signature is inaccurate, because Web Authentication is not a general-purpose API like Web Crypto. WebAuthn is an API fronting a request/response protocol for authentication challenges, and which defines binary security messages of which a signature is only a component. A digital signature provides integrity, but does not itself provide any additional security properties necessary for authentication. |
Continuation of #358.
We probably can't eliminate all of these since some of them are defined externally (e.g., "credential" and "credential source"), but anyway: these many terms are a source of some confusion and make the spec difficult for new readers.
Please expand and edit this post as more examples are found and resolved.
"credential"
"Discoverable Credentials"
"Non-discoverable Credentials"
"Authenticator Attachment"
"discoverable credential capable"
"Authentication Factor Capability"
The text was updated successfully, but these errors were encountered: