NIST defines "credential" differently #1047
Comments
|
@OR13 It's the old, legacy, person-centric view of identifiers and identities ...like the early, early versions of the DID spec. |
|
Defines differently than what definition? Furthermore, this definition of credential relates exclusively to the realm of authentication within the scope of this document, as stated in the Appendix A.1 section:
The dictionary defines credentials as: That which entitles one to confidence, credit, or authority. In the digital realm this could be further interpreted as a mean to authenticate an entity or to prove claims about an entity. Can you clarify how you feel this poses an issue and to what degree? |
|
What's the problem? It is widely known and accepted that the meaning of a term is scoped, i.e. restricted to a particular scope/context. Lawyers understand this. In legal texts (I've seen Dutch and EU such texts), it is common to have a terminology section that defines terms that are used within the scope of the particular text. While typically efforts are made not to be too far off with terminology in related scopes (other legal texts), the whole idea is that people (including lawyers, judges, etc.) have the same understanding of what is (not) an instance of a term. Software engineers know this. They have namespaces, where the name in a namespace refers e.g., to a specific variable or function, that have well-defined meanings (or else the software doesn't work). Namespaces (the equivalent of a Terminology) can be inherited, and their meanings renamed, or terms redefined. The VCDM lives in the specific context in which we want to talk, e.g., about sets of digital representations of of statements that a single party makes about a variety of entities (for which the VCDM uses the term 'credential'), and such things that also have the property of being tamper-evident and a proof of who this single party is, where the proof can be cryptographically verified (which in the VCDM terminology is a 'verifiable credential'). Having a good terminology in a context (such as VCDM) can help people to understand one another. And similar to software engineering contexts and legal contexts, this only works if people stick to the terms that are being defined, and contribute to improve their definitions such that they support us in realizing the objectives in our (VCDM) context. Looking at terms that come from other contexts is not a bad idea per se. It can help us to realize things that we hadn't thought of earlier. But there is a real risk that the meaning which I assume is appropriate in that other context is automatically assumed to be appropriate for our own context. That isn't true in general. Software engineers and lawyers know that. We may still need to learn this. |
|
@RieksJ This is a great layout of this situation and the correlation with namespaces makes a lot of sense for me. This topic got me curious enough to reach out and ask around 10 people in my circle to provide a short definition of credentials from the top of their heads. 8 out of 10 did a strong association between credentials and authentication, while 2 gave a definition related to providing documents attesting of some attribute that defines you. Given most of these people work in the tech/cybersecurity field, answers might be slightly biased. Furthermore, it's interesting to look at the ethimology of the term "credential", which was first used as "giving authority" (credentialis) or "trust" (credentia). Credential would be more of a concept than a physical object, it just happens that we call physical objects (such as diplomas) a credential. But the true meaning here is the trust that these bring. Now if we say, "sign-in with your credentials", we refer to sign in with your username/password (assuming here we have a basic authentication system). In the same way we can refer to a diploma as a credential, we can also refer to the information provided to login as a credential because they convey the concept of trust/authority. One could make the argument that as we move towards a more digital era, most people will hear/use the term credentials mostly referring to authentication instead of in a situation where they would be asked to provide credentials as in merits/list of documents, further binding the use of the word with a specific thing/scope instead of a concept. This creates an interesting communication challenge relating to the digital identity/verifiable credentials community because it's bringing the use of a term into the digital realm that already has a well established association in that environment. Now we need to have these 2 distinct use of the word coexist. Openid defines credentials as:
We can highlight similarities in all definitions that it revolves around concepts of trust/authority. And this definition clearly highlights the scope of this definition. Great topic with a slight societal undertone. I have a hard time seeing this as an issue however and more of a challenge because there is unfortunately no solution here, only a need for stronger communication. |
|
@PatStLouis Yes, we can highlight similarities, make long lists of others that have definitions of a particular term, etc. I would personally not engage with that before it was clear who would actually be using such highlighted similarities and long lists. I think, however, there is a bigger issue we need to come to grips with. The issue is that we accept that texts are being created in the context of the VCDM where terms that are actually defined, are used in a different meaning. I've seen a comment on #902) that calls to define a term that is already defined (i.e. holder. This behavior of authoring texts and accepting to work with such texts causes lots of problems which would be avoided if we just use terms as defined - raising an issue if the term needs to be adjusted. Looking at terms that are used in other contexts, e.g. OpenID, is not bad - it can inform us as we make the definitions that we need (like lawyers do in their laws). But IMHO the VCDM does need its own terminology to address the particular VCDM issues, and only use existing ones if they are understood by us in the same way, and are appropriate within the VCDM context. |
|
Yes, https://www.rfc-editor.org/rfc/rfc4949.html defines "credential" differently. |
|
+1 to clarifying that definition of credential in vc-data-model is different from the rest of the industry. |
|
The issue was discussed in a meeting on 2023-04-12
View the transcript4.4. NIST defines "credential" differently (issue vc-data-model#1047)See github issue vc-data-model#1047. Brent Zundel: issue #1047.
Brent Zundel: anyone who wishes to be assigned to this issue?
Brent Zundel: Charles in the chat will be assigned to it (voice not available). |
|
Note, lately, I found this link at NIST helpful in finding the differences in NIST terms in various documents |
1 similar comment
|
Note, lately, I found this link at NIST helpful in finding the differences in NIST terms in various documents |
|
The issue was discussed in a meeting on 2023-07-05
View the transcript2.4. NIST defines "credential" differently (issue vc-data-model#1047)See github issue vc-data-model#1047.
Kristina Yasuda: I think it's ready for PR.
Kristina Yasuda: Last time Charles agreed to be assigned - three months ago.
Manu Sporny: It depends upon what the PR does. I could be pre or post CR.
Kristina Yasuda: It may be that we will align the definition with NIST.
Brent Zundel: The most conservative thing to do is to mark it pre-CR. Kristina Yasuda: I'll mark it before CR. |
Are you asking for an exhaustive list of (links to) other vocabularies which include this term (and, I presume, every other term we define or, perhaps, use)? That's far beyond typical, and virtually impossible to satisfy. The NIST link @shigeya provided shows that even within NIST, there are multiple definitions for this term. That should be enough evidence that we need not catalog all other vocabularies and their definitions of this (and our other) term(s), given that we are providing clear statements of the definition(s) we're using for these terms. |
|
Either reference other organizations terms directly, or add an informative section supporting disambiguation I am starting to favor the second option, since it seems the first will make spec comprehension harder. |
Sakurann
added
the
ready for PR
|
The issue was discussed in a meeting on 2023-08-02
View the transcript2.5. NIST defines "credential" differently (issue vc-data-model#1047)See github issue vc-data-model#1047.
Kristina Yasuda: Manu sent out of an email about test suite adoption, we'll discuss that in an upcoming call. Orie Steele: I think the core data model has terminology, and sometimes it aligns strongly w/ existing definition, and sometimes it doesn't... Data Integrity specs had NIST relationships with them, we should be cautious to refer to NIST w/o referring to their terminology... NIST has conflicting definitions for these things... looking at you "attestation" -- highly problematic.
Orie Steele: To resolve this, we either go through our terms and add references to other sources so you can navigate them, or to create informative part wrt. disambiguation and do that outside of term list so our term list can stay clean, small, instead of us trying to rationalize how others have defined their terminology.
Kristina Yasuda: other ways to do this? Michael Prorock: RFC4949 defines some of this stuff -- they cite a bunch of other definitions because there are multiple definitions... would like to point to work/reviewed published -- or creating definition of term that is confusing to those trrying to integrate w/ our stuff... Kristina Yasuda: We have Charles assigned... should we add Orie?
Sebastian Crane: I don't want to negate effort of those compiling glossaries in the past, don't think average is going to look at our use of "credential" and say "my implementation isn't accurate"... it might be useful from a marketing perspective, but probably won't affect implementability of VCs.
Manu Sporny: +1 to seabass. |
|
Partially addressed by #1260 |
|
The issue was discussed in a meeting on 2023-08-30
View the transcript4.4. NIST defines "credential" differently (issue vc-data-model#1047)See github issue vc-data-model#1047. Brent Zundel: NIST defines credential differently. Orie Steele: I definitely need to get to it. Brent Zundel: is the some point anticipated before TPAC. Orie Steele: possibly, but this should probably be post-CR. Brent Zundel: comments to that effect with link to PR would be helpful. Justin Richer: the TLDR version is that 800-63 definition of credential is authenticator plus attributes. Orie Steele: the group has been discussing how to express "confidenceMethod" in VCs, which would express the public key that would be used for an authenticator.
Brent Zundel: moving to next issue.
Brent Zundel: we added context resource integrity. how do we test it?
Michael Prorock: I will be adding code for testing the jose-cose side of this. Manu Sporny: +1 should be straightforward to add.
Brent Zundel: should we move this to the test suite repo? Manu Sporny: or we just test in the core data model.
Brent Zundel: If I here no issues, I'll move to vc test suite repo.
|
|
The issue was discussed in a meeting on 2023-09-14
View the transcript5.2. NIST defines "credential" differently (issue vc-data-model#1047)See github issue vc-data-model#1047.
Manu Sporny: Orie suggested that we added an informative section to disambiguate the terms. Brent Zundel: I'll mark this as ready for PR with that. |
OR13
added
pr exists
and removed
ready for PR
|
PR #1332 has been merged, closing. |
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-4.ipd.pdf
EDITED to clarify the ask:
The working group should provide citations for other vocabularies, and explain why their definitions are useable or not.
We should also refer to https://www.ietf.org/rfc/rfc4949.txt
The text was updated successfully, but these errors were encountered: