You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Purpose

In order to be properly relied upon, every verifiable credential must be associated with a stated level of assurance.  Since there are infinite variables in play to determine the level of assurance to be assumed, it is best to classify verifiable credentials in discrete class levels.  This will allow a set of policies, practices and infrastructure to be defined and associated with specific classes.  In the pre-verifiable credential world of the internet a variety of difference class structures are loosely defined depending on where a credential is stored and the level of authentication is used on the contents of a digital certificate.  Multi-factor verification techniques are also used to upgrade amorphous classes of certificates and traffic.All Internet transactions and Verifiable Credentials have different purposes.  

In the context of today's Internet traffic, transaction are mostly untrusted which has led to digital identity theft, spoofing, man in the middle attacks and ransomware.  The advent of verifiable credentials brings the promise of a more trustworthy infrastructure for reliable transactions.  When that infrastructure is combined with other trust assurance elements, verifiable credentials can be highly trustworthy and relied upon for a myriad of transformative digital applications.

The US National Institute of Standards (NIST) has published (https://pages.nist.gov/800-63-3/sp800-63-3.html) generally accepted associated classes as it relates to identity credentials. Digital identity as a legal identity further complicates the definition and ability to use digital identities across a range of social and economic use cases. Digital identity is hard. Proving someone is who they say they are — especially remotely, via a digital service — is fraught with opportunities for an attacker to successfully impersonate someone.  The standards associated with identity assurance create a solid model for other claims made in a verifiable credential

The components of identity assurance detailed in the NIST guidelines are as follows:

  • IAL refers to the identity proofing process.
    • IAL1: There is no requirement to link the applicant to a specific real-life identity. Any attributes provided in conjunction with the authentication process are self-asserted or should be treated as such (including attributes a Credential Service Provider, or CSP, asserts to an RP).
    • IAL2: Evidence supports the real-world existence of the claimed identity and verifies that the applicant is appropriately associated with this real-world identity. IAL2 introduces the need for either remote or physically-present identity proofing. Attributes can be asserted by CSPs to RPs in support of pseudonymous identity with verified attributes.
    • IAL3: Physical presence is required for identity proofing. Identifying attributes must be verified by an authorized and trained representative of the CSP. As with IAL2, attributes can be asserted by CSPs to RPs in support of pseudonymous identity with verified attributes.
  • AAL refers to the authentication process.
    • AAL1: AAL1 provides some assurance that the claimant controls an authenticator bound to the subscriber’s account. AAL1 requires either single-factor or multi-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator through a secure authentication protocol.
    • AAL2: AAL2 provides high confidence that the claimant controls authenticator(s) bound to the subscriber’s account. Proof of possession and control of two distinct authentication factors is required through secure authentication protocol(s). Approved cryptographic techniques are required at AAL2 and above.
    • AAL3: AAL3 provides very high confidence that the claimant controls authenticator(s) bound to the subscriber’s account. Authentication at AAL3 is based on proof of possession of a key through a cryptographic protocol. AAL3 authentication SHALL use a hardware-based authenticator and an authenticator that provides verifier impersonation resistance; the same device MAY fulfill both these requirements. In order to authenticate at AAL3, claimants SHALL prove possession and control of two distinct authentication factors through secure authentication protocol(s). Approved cryptographic techniques are required.
  • FAL refers to the strength of an assertion in a federated environment, used to communicate authentication and attribute information (if applicable) to a relying party (RP).
    • FAL1: Allows for the subscriber to enable the RP to receive a bearer assertion. The assertion is signed by the IdP using approved cryptography.
    • FAL2: Adds the requirement that the assertion be encrypted using approved cryptography such that the RP is the only party that can decrypt it.
    • FAL3: Requires the subscriber to present proof of possession of a cryptographic key referenced in the assertion in addition to the assertion artifact itself. The assertion is signed by the IdP and encrypted to the RP using approved cryptography.

Identity proofing establishes that a subject is who they claim to be.  The process of identity proofing can be translated to other claims made in a verifiable credential.  Digital authentication establishes that a subject attempting to access a digital service is in control of one or more valid authenticators associated with that subject’s digital identity. For services in which return visits are applicable, successfully authenticating provides reasonable risk-based assurances that the subject accessing the service today is the same as that which accessed the service previously.  This directly translates to the usage of verifiable credentials

In addition to NIST levels above,  other standards have addressed levels of assurance that are applied to the classess of verifiable credeintials:

Pan-Canadian Trust Framework (PCTF) Levels of Assurance (LOA) Qualifiers
The current version of the PCTF conformance criteria use the four PanCanadian Levels of Assurance (LOA):

  • Level 1: little or no confidence required
  • Level 2: some confidence required
  • Level 3: high confidence required
  • Level 4: very high confidence required

eIDAS (electronic IDentification, Authentication and trust Services) is an EU regulation on electronic identification and trust services for electronic transactions in the European Single Market.  eIDAS has established level of Assuarnce qualifiers which can be used in verifiable credential classification. eIDAS qualifiers may be based on the three levels of assurance defined by the European Regulation No 910/2014 on electronic identification and trust services for electronic transactions:

  • Low: low degree of confidence
  • Substantial: substantial degree of confidence 
  • High: high degree of confidence


Classes below also consider Vectors of Trust, a proposed IETF standard (RFC 8485, October 2018). Currently, the VoT proposal consists of four components that may be used as qualifiers:

  • Identity Proofing (P): describes how likely it is that a given digital identity transaction corresponds to a particular, realworld identity
  • P0: No proofing is done, and data is not guaranteed to be persistent across sessions
  • P1: Attributes are self-asserted but consistent over time, potentially pseudonymous
  • P2: Identity has been proofed either in person or remotely using trusted mechanisms (such as social proofing)
  • P3: There is a binding relationship between the identity provider and the identified party (such as signed/notarized documents and employment records)

Primary Credential Usage (C): defines how strongly the primary credential can be verified. The primary credential usage component of this attribute represents distinct categories of primary credential that MAY be used together in a single transaction. Multiple distinct values from this category MAY be used in a single transaction.

  • C0: No credential is used / anonymous public service
  • Ca: Simple session HTTP cookies (with nothing else)
  • Cb: Known device, such as those indicated through device posture or device management systems
  • Cc: Shared secret, such as a username and password combination
  • Cd: Cryptographic proof of key possession using shared key
  • Ce: Cryptographic proof of key possession using asymmetric key
  • Cf: Sealed hardware token / keys stored in a trusted platform module
  • Cg: Locally verified biometric


  • Primary Credential Management The primary credential management component of this vector definition represents distinct categories of management that MAY be considered separately or together in a single transaction. Many trust framework deployments MAY use a single value for this component as a baseline for all transactions and thereby omit it. Multiple distinct values from this category MAY be used in a single transaction. Ma: Self-asserted primary credentials (user chooses their own credentials and must rotate or revoke them manually) / no additional verification for primary credential issuance or rotation Mb: Remote issuance and rotation / use of backup recover credentials (such as email verification) / deletion on user request Mc: Full proofing required for each issuance and rotation / revocation on suspicious activity Richer & Johansson Standards Track [Page 20]
  • RFC 8485 Vectors of Trust October 2018 A.4. Assertion Presentation The assertion presentation component of this vector definition represents distinct categories of assertion that are RECOMMENDED to be used in a subsumptive manner but MAY be used together. Multiple distinct values from this category MAY be used in a single transaction. Aa: No protection / unsigned bearer identifier (such as an HTTP session cookie in a web browser) Ab: Signed and verifiable assertion, passed through the user agent (web browser) Ac: Signed and verifiable assertion, passed through a back channel Ad: Assertion encrypted to the RP's key
    subject



 Primary Credential Management (M): conveys information
about the expected lifecycle of the primary credential in use,
including its binding, rotation, and revocation
 Assertion Presentation (A): defines how well the TDI can be
communicated across the network without information leaking
to unintended parties and without spoofing

in order to define discrete class of verifiable transactions, it is key to identify the variables that make a credential more trustable.  The following are factors embodied in the class definitions:

  • Credential defined in a Governance Framework at a stated level of assurance
  • The degree of assurance that the public key of the signer in a verifiable credential is matched to the possessor of the private key
  • The degree of authentication of data that is performed on the contents of a verifiable credential
  • The security and protection of the wallet containing the credential
  • The security and availability of a registry containing in the credential (if not held in a wallet)
  • The security and availability of the public key in a credential for verification purposes
  • The trustworthiness of the personnel and infrastructure of the Issuer of a verifiable credential
  • The asserted policies of the Issuer
  • The degree that practices that meet the Issuer policies are part of a trust assurance scheme
  • The rigor of a trust assurance scheme of the ecosystem that governs the credential


Class 1 – Untrusted

  • Credential defined in a Governance Framework at a stated level of assurance: No
  • The degree of assurance that the public key of the signer in a verifiable credential is matched to the possessor of the private key: No assurance
  • The degree of authentication of data that is performed on the contents of a verifiable credential: None
  • The security and protection of the wallet containing the credential: None
  • The security and availability of a registry containing in the credential (if not held in a wallet): No controls
  • The security and availability of the public key in a credential for verification purposes: No requirements
  • The trustworthiness of the personnel and infrastructure of the Issuer of a verifiable credential: No requirements
  • The asserted policies of the Issuer: No requirements
  • The degree that practices that meet the Issuer policies are part of a trust assurance scheme: No trust assurance scheme
  • The rigor of a trust assurance scheme of the ecosystem that governs the credential: No trust assurance scheme
  • Mapped Level to other Standards:
    • NIST 800-63-3: IAL1, AAL1, FAL1
    • PCTF: Level 1


Class 2 – Minimum Internet Grade

  • Attributes of Class:
    • Minimum Level of Assurance Covered by ToIP Foundation Guidance
  • Examples of Transactions: Identity Credential Used for non-Asset Transfer
  • Examples of Verifiable Credentials
  • Governance Mechanisms
  • Underlying Infrastructure
  • Trust Assurance Practices
  • Mapped Level to other Standards:
    • NIST 800-63-3: IAL2, AAL2, FAL?
    • PCTF: Level 2
    • eIDAS: Simple

Class 3 – Asset Value Grade

  • Attributes of Class:
    • Identity Credential Used for Asset Transfer
  • Examples of Transactions: AML/CFT
  • Examples of Verifiable Credentials
  • Governance Mechanisms
  • Underlying Infrastructure
  • Trust Assurance Practices
  • Mapped Level to other Standards:
    • NIST 800-63-3: IAL2, AAL3, FAL?
    • PCTF Level 3
    • eIDAS: Qualified

Class 4 – High Assurance Grade

  • Attributes of Class:
  • Examples of Transactions:
  • Examples of Verifiable Credentials
  • Governance Mechanisms
  • Underlying Infrastructure
  • Trust Assurance Practices
  • Mapped Level to other Standards:
    • NIST 800-63-3: IAL3, AAL3, FAL?
    • PCTF Level 4
    • eIDAS: Qualified
  • No labels