An Engagement Context Role (ECR) is a person who represents a Legal Entity in a functional or engagement-specific context (rather than an official organizational position) and is issued an ECR vLEI Credential to cryptographically verify their authorization for that specific engagement.
Related Concepts
No related concepts available
Comprehensive Explanation
engagement-context-role
Official Definition
An Engagement Context Role (ECR) is formally defined in the Legal Entity Engagement Context Role vLEI Credential Governance Framework as a person who represents a Legal Entity in a functional role or other context of engagement that is distinct from official organizational positions. The ECR Person is issued an ECR vLEI Credential that cryptographically binds their identity to their authorized role within a specific engagement context.
Official Abbreviation: ECR
Canonical Source: The authoritative definition appears in the vLEI Ecosystem Governance Framework v3.0, specifically in Document 1 (2022-11-23 Legal Entity Engagement Context Role vLEI Credential Governance Framework) and Document 4 (2025-04-16 vLEI EGF v3.0 Legal Entity Engagement Context Role vLEI Credential Framework v1.4).
Key Distinction: ECR credentials address functional, project-based, consultancy, and external engagement scenarios where individuals need verifiable proof of their authorized roles without implying permanent employment or official organizational positions. This distinguishes ECR from Official Organizational Role (OOR) credentials, which are reserved for formal positions within a Legal Entity's organizational hierarchy (e.g., CEO, CFO, Board Members).
Governance Context
Position in vLEI Ecosystem
The ECR credential type occupies a critical position in the vLEI ecosystem hierarchy:
Implementation Notes
Governance Implementation
For Legal Entities implementing ECR credential programs:
Policy Development: Establish clear internal policies distinguishing when ECR credentials are appropriate versus OOR credentials. Document criteria for engagement contexts that warrant ECR issuance.
LAR Authorization: Designate Legal Entity Authorized Representatives with authority to approve ECR credential requests. Implement multi-signature workflows if required by organizational structure.
QVI Selection: Contract with Qualified vLEI Issuers who can provide ECR credential issuance services. Evaluate QVI capabilities for identity verification and OOBI authentication.
Lifecycle Management: Implement processes to track ECR credential lifecycles, including:
Integration with approved digital identity schemes
OOBI session infrastructure (audio/video)
Challenge-response authentication systems
Authorization Processing: Implement workflows to receive and validate ECR Authorization credentials from Legal Entities before issuing ECR credentials.
Registry Management: Maintain credential registries (TELs) for revocation checking and status management.
Multi-Signature Support: For Legal Entities with multi-signer requirements, implement workflows to collect and verify multiple LAR signatures on authorization credentials.
For Verifiers implementing ECR credential verification:
Chain Verification: Implement full credential chain verification from ECR credential through ECR Authorization, Legal Entity credential, QVI credential, to GLEIF root.
Revocation Checking: Query all levels of the credential chain for revocation status, not just the ECR credential itself.
Trust Chain Position:
GLEIF Root - Global Legal Entity Identifier Foundation as root authority
Qualified vLEI Issuers (QVIs) - Organizations authorized by GLEIF to issue credentials
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:
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.
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.
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.
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.
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:
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)
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
Business Logic: Develop appropriate business logic to evaluate whether the engagementContextRole field is suitable for the requested transaction or access.
Privacy Respect: Request only necessary attributes through selective disclosure mechanisms; avoid over-collection of personal information.
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.