Confidence levels (from the issuer)

[denkeni]

It could be helpful to add a new field of confidenceLevel or assuranceLevel, allowing the issuer to indicate how it authenticated the subject before issuing the credential.

The value could be some widely adopted frameworks, such as:

• Identity Assurance Level (IAL) 1-3 from NIST SP 800-63
• Levels of Assurance (LoA) 1-4 from ISO/IEC 29115
• Assurance level low, substantial, high from eIDAS Article 8
• …etc.

In practice, some high-risk services (e.g., banking) might only accept credentials with the highest assurance level, while most other applications do not require that.

This addition would be informative and contribute to the broader trust model described in VCDM 2.0.

[TallTed]

It could be helpful to add a new field of confidenceLevel or assuranceLevel, allowing the issuer to indicate how it authenticated the subject before issuing the credential.

The suggested fields (confidenceLevel or assuranceLevel) don't make intuitive sense to me, and I cannot support nor advise continuing to use them to describe how anything was authenticated, whether that is the identity of the VC requester/recipient or an attribute of that or any other entity. (These lexical values are technically opaque, but that is not how most humans will read them. They are constructed from English words, and most readers will understand those words as keeping their commonly understood meanings, no matter what the intent nor the officially published meanings of such fieldnames.)

I am unspeakably disappointed in NIST, ISO/IEC, and eIDAS that they seem to be using (or have published sufficiently unclear descriptions that indicate to you that they are using) confidence and/or assurance to describe a method of authenticating a subject (which entity may not be involved in or even know about a VC's issuance at all!) before issuing a VC.

confidenceLevel and assuranceLevel imply to me (and will imply to most readers who read English) a subjective evaluation of confidence or assurance in some attribute's value, or in the source of that value.

confidenceMethod or assuranceMethod, on the other hand, might understandably be used to indicate how an Issuer evaluated the value of an attribute of a Subject — which could include the identifier (i.e., the URI that identifies) a Subject of the VC — before the VC was issued.

All that said...

This issue mostly feels to me like Verification business logic, which is the sole purview of the current Verifier, not any Issuer nor any previous Verifier nor any Subject. It is certainly possible for Verifiers in "high-risk services" to accept VCs only from a limited set of Issuers who use whatever confidenceMethod or assuranceMethod those Verifiers find acceptable, but this is not something that we can really standardize for all and sundry.