Trust Chain Position:

1. GLEIF Root - Global Legal Entity Identifier Foundation as root authority
2. Qualified vLEI Issuers (QVIs) - Organizations authorized by GLEIF to issue credentials
3. Legal Entities - Organizations holding Legal Entity vLEI Credentials
4. ECR Persons - Individuals holding ECR vLEI Credentials for specific engagement contexts

GLEIF Governance Framework

The ECR credential operates under the comprehensive GLEIF vLEI Ecosystem Governance Framework, which establishes:

• Issuance policies for ECR credentials
• Identity verification requirements for ECR Persons
• Technical specifications using KERI and ACDC protocols
• Revocation procedures when engagement contexts end
• Privacy protections for personally identifiable information

Related Governance Entities

The ECR governance framework interacts with several key entities:

• Legal Entity Authorized Representatives (LARs): Individuals authorized by Legal Entities to request ECR credential issuance
• QVI Authorized Representatives (QARs): Representatives of QVIs who perform identity verification and issue ECR credentials
• GLEIF Authorized Representatives (GARs): GLEIF representatives who manage the root trust infrastructure

Roles & Responsibilities

Primary Responsibilities

An ECR Person's responsibilities are context-specific and defined by the engagement for which the credential was issued. Common scenarios include:

Project-Based Roles:

• Project managers for specific initiatives
• Technical consultants engaged for defined scopes of work
• External auditors conducting specific assessments
• Temporary specialists providing expertise for limited engagements

Functional Roles:

• Supply chain coordinators managing specific vendor relationships
• Security consultants performing assessments
• Compliance specialists engaged for regulatory projects
• Integration partners working on system implementations

Cross-Organizational Roles:

• Joint venture representatives from partner organizations
• Consortium participants in multi-party initiatives
• Alliance coordinators managing partnership activities

Authority and Permissions

The ECR credential grants verifiable authorization for specific activities:

Cryptographic Verification: The ECR vLEI Credential provides cryptographically verifiable proof that:

• The ECR Person's identity has been verified to at least Identity Assurance Level 2 (IAL2) standards
• The Legal Entity has explicitly authorized this person for the specified engagement context role
• The credential remains valid and has not been revoked
• The person controls the AID (Autonomic Identifier) bound to the credential

Scope of Authorization: Unlike OOR credentials that convey broad organizational authority, ECR credentials are narrowly scoped to:

• Specific engagement contexts (e.g., "Supply Chain Integration Project")
• Defined time periods (though not always explicitly time-bounded)
• Particular functional areas (e.g., "Security Assessment", "Compliance Review")
• Limited transactional authority as defined by the engagement

Presentation Capabilities: ECR Persons can:

• Present their credentials to verifiers who need to confirm their authorization
• Participate in IPEX exchanges (Issuance and Presentation Exchange protocol)
• Prove their relationship to the Legal Entity for specific purposes
• Demonstrate authorization without revealing unnecessary personal information through selective disclosure

Limitations

Explicit Limitations:

1. No Official Organizational Authority: ECR credentials do not convey the authority of official organizational positions. An ECR Person cannot act as an official representative of the Legal Entity beyond their specific engagement context.

2. Context-Specific Only: Authorization is limited to the specific engagement context described in the credential's engagementContextRole attribute. The credential does not grant general authority.

3. Dependent on Legal Entity Credential: The ECR credential's validity depends on the continued validity of the underlying Legal Entity vLEI Credential. If the Legal Entity's credential is revoked, all dependent ECR credentials become invalid.

4. Revocable by Legal Entity: The Legal Entity (through its LARs) can revoke ECR credentials at any time, immediately terminating the ECR Person's verifiable authorization.

5. No Delegation Rights: ECR Persons typically cannot delegate their authority to others or issue credentials on behalf of the Legal Entity.

Credential Lifecycle

Issuance Process

The ECR credential issuance follows a dual-path model depending on organizational structure:

Path 1: QVI-Mediated Issuance (Multi-Signer Organizations)

Step 1 - Authorization Phase:

• Legal Entity Authorized Representatives (LARs) prepare an ECR Authorization vLEI Credential (schema SAID: EH6ekLjSr8V32WyFbGe1zXjTzFs9PkTYmupJ9H65O14g)
• This authorization credential specifies:
  • The ECR Person's AID
  • The ECR Person's legal name (as verified during identity assurance)
  • The specific engagement context role description
  • The Legal Entity's LEI
• Multi-signature requirements: Signatures must match the signing threshold of the Legal Entity vLEI Credential's AID
• The authorization credential is issued to the QVI, granting permission to issue the actual ECR credential

Step 2 - Identity Verification:

• QVI Authorized Representatives (QARs) conduct identity verification of the ECR Person
• Identity Assurance to at least IAL2 standards per NIST 800-63A
• Alternative pathways include presentation of valid digital identity credentials from approved schemes:
  • European eIDAS schemes (High/Substantial Level)
  • Asian schemes (Singapore SingPass, India Aadhaar, etc.)
  • Latin American schemes (Brazil e-CPF)

Step 3 - OOBI Authentication:

• Real-time OOBI session (Out-of-Band Introduction) conducted via audio/video
• Manual verification of legal identity credentials
• Bidirectional AID exchange between LAR and ECR Person
• Challenge-response authentication using private key stores
• Prohibition of video filters and avatars to ensure authentic identity verification

Step 4 - Credential Issuance:

• QAR issues the ECR vLEI Credential (schema SAID: EEy9PkikFcANV1l7EHukCeXqrzT1hNZjGlUk7wuMO5jw)
• Credential includes:
  • ECR Person's AID
  • Legal Entity's LEI
  • Person's legal name
  • Engagement context role description (free-text field)
  • Issuance datetime
• Edges block creates cryptographic chain to ECR Authorization credential
• Credential registered in QVI's credential registry

Path 2: Direct Legal Entity Issuance (Sole Proprietor Organizations)

For Legal Entities with single authorized signers:

• LAR directly issues the ECR credential without QVI intermediation
• Simplified workflow with LAR performing both authorization and issuance
• Same identity verification requirements apply
• Same OOBI authentication procedures required
• Same credential schema used

Verification Procedures

Verifier Responsibilities:

When an ECR Person presents their credential, verifiers must:

1. Cryptographic Verification:

   • Verify the credential's SAID (Self-Addressing Identifier) integrity
   • Validate the issuer's digital signature
   • Confirm the credential conforms to the official schema
   • Verify the CESR encoding is valid

2. Chain Verification:

   • Verify the authorization chain through the edges block
   • Confirm the ECR Authorization credential exists and is valid
   • Verify the Legal Entity vLEI Credential is valid
   • Trace the chain back to the QVI credential and ultimately GLEIF's root

3. Revocation Checking:

   • Query the credential's registry (identified by ri field)
   • Confirm the credential has not been revoked
   • Check the Legal Entity's credential status (parent credential)
   • Verify the QVI's credential remains valid

4. AID Control Verification:

   • Verify the presenter controls the AID specified in the credential
   • Validate signatures on presentation messages
   • Confirm key state through the KEL (Key Event Log)

5. Context Appropriateness:

   • Evaluate whether the engagementContextRole is appropriate for the transaction
   • Determine if the credential's scope matches the requested action
   • Apply business logic to authorization decisions

Verification Context Independence: The governance framework mandates that ECR credentials must fulfill proof requests regardless of context - whether in-person, online, or telephonic interactions.

Revocation Conditions

ECR credentials may be revoked under several conditions:

Explicit Revocation by Legal Entity:

• Engagement termination: When the project, consultancy, or engagement ends
• Authorization withdrawal: When the Legal Entity decides to terminate the ECR Person's authorization
• Security concerns: If the ECR Person's AID is compromised or suspected of compromise
• Policy violations: If the ECR Person violates terms of engagement

Automatic Revocation Triggers:

• Parent credential revocation: If the Legal Entity vLEI Credential is revoked, all dependent ECR credentials become invalid
• QVI termination: If the issuing QVI's credential is revoked (though grace periods may apply)
• LEI status change: If the Legal Entity's LEI becomes inactive or retired

Revocation Process:

• LARs initiate revocation through the QVI (for QVI-issued credentials) or directly (for LE-issued credentials)
• Revocation is recorded in the credential's TEL (Transaction Event Log)
• Revocation is immediately effective and verifiable by all parties
• No grace period typically applies to ECR revocations (unlike some other credential types)

Related Governance Documents

Primary Governance Framework

Legal Entity Engagement Context Role vLEI Credential Governance Framework:

• Version: v1.4 (2025-04-16)
• Document ID: Part of vLEI EGF v3.0
• Scope: Comprehensive policies for ECR credential issuance, verification, and revocation
• Key Sections:
  • Purpose and principles (binding to holder, context independence)
  • Issuer qualification requirements
  • Identity verification procedures (IAL2, OOBI authentication)
  • Credential schema specifications
  • Multi-signature requirements
  • Revocation policies

Supporting Governance Documents

vLEI Ecosystem Governance Framework v3.0 Primary Document:

• Establishes GLEIF as governing authority
• Defines stakeholder roles and responsibilities
• Sets core policies applicable to all credential types
• Establishes trust chain architecture

Legal Entity vLEI Credential Governance Framework:

• Governs the parent credential required for ECR issuance
• Defines Legal Entity identity verification
• Establishes LAR authorization procedures

Qualified vLEI Issuer Authorization vLEI Credential Framework:

• Governs the ECR Authorization credential (schema EH6ekLjSr8V32WyFbGe1zXjTzFs9PkTYmupJ9H65O14g)
• Defines authorization workflow between Legal Entities and QVIs
• Establishes multi-signature requirements for authorization

vLEI Ecosystem Information Trust Policies:

• Privacy and data protection requirements
• Security policy framework
• Incident management procedures
• Compliance requirements (GDPR, ISO 27001)

vLEI Ecosystem Risk Assessment:

• Risk analysis for ECR credential issuance
• Mitigation strategies for identity verification failures
• Operational risk management

Technical Specifications

Technical Requirements Part 1: KERI Infrastructure:

• KERI specification version management
• Witness pool configuration requirements
• Key management infrastructure
• AID generation and rotation policies

Technical Requirements Part 2: vLEI Credentials:

• ACDC implementation requirements
• CESR encoding specifications
• Credential schema compliance
• IPEX protocol requirements

Technical Requirements Part 3: vLEI Credential Schema Registry:

• Official schema publication
• SAID-based schema identification
• Semantic versioning policies
• Backward compatibility requirements

Schema Specifications

ECR vLEI Credential Schema:

• Schema SAID: EEy9PkikFcANV1l7EHukCeXqrzT1hNZjGlUk7wuMO5jw
• Version: 1.0.0
• Repository: GLEIF-IT/vLEI-schema
• Required Fields: AID, datetime, LEI, personLegalName, engagementContextRole
• Edges: Authorization chain to ECR Auth credential

ECR Authorization vLEI Credential Schema:

• Schema SAID: EH6ekLjSr8V32WyFbGe1zXjTzFs9PkTYmupJ9H65O14g
• Version: 1.0.0
• Repository: GLEIF-IT/vLEI-schema
• Purpose: Authorizes QVI to issue ECR credential to specific person
• Edges: Chain to Legal Entity vLEI Credential

Implementation Considerations

Distinguishing ECR from OOR

Implementers must understand the critical distinction between ECR and OOR credentials:

Use ECR credentials when:

• The role is temporary, project-based, or consultancy-related
• The person is not a permanent employee or official representative
• The authorization is context-specific rather than organization-wide
• The role is functional (e.g., "Security Consultant") rather than positional (e.g., "Chief Security Officer")

Use OOR credentials when:

• The role is an official organizational position (CEO, CFO, Board Member)
• The person has formal authority to represent the Legal Entity
• The role is permanent or long-term within the organizational structure
• The authorization is organization-wide rather than context-specific

Privacy Considerations

ECR credentials contain personally identifiable information (PII):

• Legal name of the ECR Person
• AID that may be correlatable across contexts
• Engagement context role that may reveal sensitive business relationships

Privacy protections:

• Selective disclosure mechanisms in ACDC
• Compact disclosure options (SAID-only revelation)
• Chain-link confidentiality for controlled information sharing
• GDPR compliance requirements in governance framework

Scalability and Flexibility

The ECR credential design enables:

Horizontal Scalability:

• Legal Entities can issue unlimited ECR credentials for different engagement contexts
• No artificial limits on number of ECR Persons per Legal Entity
• Supports large-scale contractor/consultant management

Vertical Flexibility:

• Free-text engagementContextRole field allows any role description
• No predefined taxonomy or code list constraints
• Organizations define roles appropriate to their business needs
• Supports diverse industries and use cases

Delegation Patterns:

• ECR credentials can be chained to create sub-delegations (though not explicitly required)
• Supports complex organizational relationships
• Enables multi-party engagements with clear authorization paths

Interoperability

ECR credentials are designed for universal interoperability:

• KERI-based: Works with any KERI-compliant infrastructure
• ACDC-compliant: Compatible with all ACDC verifiers
• CESR-encoded: Supports both text and binary representations
• Schema-driven: JSON Schema validation ensures consistency
• IPEX-enabled: Participates in standard presentation exchange protocols

Operational Considerations

For Legal Entities:

• Establish clear policies for when ECR vs. OOR credentials are appropriate
• Implement LAR authorization workflows for ECR requests
• Monitor ECR credential lifecycle and revoke when engagements end
• Maintain records of issued ECR credentials for audit purposes

For QVIs:

• Implement robust identity verification procedures meeting IAL2 standards
• Establish OOBI session infrastructure for real-time authentication
• Maintain credential registries for revocation checking
• Provide clear documentation for Legal Entity customers

For Verifiers:

• Implement full chain verification (ECR → ECR Auth → LE → QVI → GLEIF)
• Check revocation status at all levels of the chain
• Apply appropriate business logic to evaluate engagement context appropriateness
• Respect privacy through minimal disclosure requests

Technical Considerations

Schema Validation: ECR credentials must validate against schema SAID EEy9PkikFcANV1l7EHukCeXqrzT1hNZjGlUk7wuMO5jw. Implementers should retrieve the official schema from the GLEIF-IT/vLEI-schema repository.

Edge Verification: The edges block in ECR credentials creates a cryptographic chain to the ECR Authorization credential. Verifiers must resolve and validate this chain using the n (node SAID) and s (schema SAID) fields.

Free-Text Role Field: The engagementContextRole field is free-text, allowing flexibility but requiring verifiers to implement appropriate parsing and evaluation logic for their use cases.

AID Control Verification: Always verify that the presenter controls the AID specified in the credential by validating signatures on presentation messages against the current key state in the KEL.