Comprehensive Explanation

bis (Backed VC Issue)

Process Definition

bis represents a registry-backed verifiable credential issuance operation within the KERI ecosystem. The term is an abbreviation with two equivalent expansions:

1. backed vc issue - emphasizing the registry-backed nature of the operation
2. registry-backed transaction event log credential issuance - the full technical description

The bis operation accomplishes several critical functions:

• Creates a verifiable record of credential issuance in a Transaction Event Log (TEL)
• Anchors the issuance event to the issuer's Key Event Log (KEL) through cryptographic seals
• Establishes the initial state of the credential as "issued" in the registry
• Enables future state transitions including revocation (brv) operations
• Provides cryptographic proof that the credential was issued by the controller of a specific AID

When bis is Used

The bis operation is invoked when:

• An issuer creates a new ACDC credential and wants to track its lifecycle
• The credential requires revocability (non-revocable credentials may not need TEL backing)
• The issuer needs to provide verifiable proof of issuance to third parties
• The credential is part of a public verifiable credential registry
• Compliance or governance frameworks require auditable issuance records

Key Participants

The bis operation involves several participants:

1. Issuer: The controller of an AID who creates and signs the credential
2. Issuer's KEL: The Key Event Log that establishes the issuer's control authority
3. TEL Registry: The Transaction Event Log that tracks credential state
4. Registrars (Backers): Entities that maintain copies of the TEL (analogous to witnesses for KELs)
5. Issuee: The subject of the credential (may be the same as or different from the recipient)

Process Flow

Step 1: Credential Creation

The issuer constructs an ACDC credential with required fields:

• v: Version string identifying the ACDC protocol version
• d: SAID of the credential (self-addressing identifier)
• i: Issuer AID (the autonomic identifier of the credential issuer)
• ri: Registry Identifier (the SAID of the TEL registry tracking this credential)
• s: Schema SAID or schema block
• a: Attribute block or SAID (the claims being made)
• Additional optional fields (e for edges, r for rules, u for UUID)

The credential structure must be serialized in a canonical form (typically JSON, CBOR, or MGPK) to enable SAID computation.

Step 2: TEL Inception Event Creation

If this is the first credential being issued to a new TEL registry, a management TEL inception event must be created first. This event:

• Establishes the TEL registry identifier (ri)
• Specifies the list of Registrars (backers) for the TEL
• Defines the registry configuration and thresholds
• Is anchored to the issuer's KEL through an event seal

For subsequent credentials using an existing registry, this step is skipped.

Step 3: VC TEL Issuance Event Creation

The issuer creates a VC TEL issuance event with the following structure:

{
  "v": "KERI10JSON00011c_",
  "i": "<credential SAID>",
  "s": "0",
  "t": "iss",
  "ri": "<registry identifier>",
  "dt": "2024-01-15T10:30:00.000000+00:00"
}

Key fields:

• i: The SAID of the credential being issued
• s: Sequence number (0 for issuance, incremented for subsequent state changes)
• t: Event type ("iss" for issuance)
• ri: Reference to the management TEL
• dt: ISO 8601 timestamp of issuance

Step 4: KEL Anchoring

The TEL issuance event is anchored to the issuer's KEL through an event source seal. This involves:

1. Computing the digest of the serialized TEL issuance event
2. Creating an event source seal triple: (s, d) where:
   • s: Sequence number of the TEL event
   • d: Digest of the TEL event
3. Including this seal in either:
   • An interaction event in the issuer's KEL (most common)
   • A rotation event if key rotation is occurring simultaneously

The KEL event containing the seal is signed by the issuer's current authoritative keys, creating a cryptographic commitment to the TEL event.

Step 5: Registrar Distribution

The TEL issuance event and its anchoring KEL event are distributed to the configured Registrars. Each Registrar:

1. Validates the TEL event structure
2. Verifies the anchoring seal in the KEL event
3. Validates the KEL event signatures against the issuer's current key state
4. Stores the TEL event in its local database
5. May provide a receipt confirming acceptance

This distribution ensures redundancy and availability of the credential state information.

Step 6: State Confirmation

The issuer (or any validator) can query the Registrars to confirm the credential state:

1. Request the current state for the credential SAID
2. Receive responses from multiple Registrars
3. Apply BADA (Best Available Data Acceptance) policy to determine authoritative state
4. Verify that the state is "issued" with sequence number 0

State Changes and Transitions

After bis completes, the credential state is:

• Status: Issued
• Sequence number: 0
• Registry: Linked to the specified TEL registry
• Issuer: Cryptographically bound to the issuer's AID

Possible subsequent state transitions:

• brv (revocation): Changes state to "revoked" with incremented sequence number
• Transfer operations: If the credential supports transferability
• Additional state updates: Depending on the TEL configuration

Decision Points

Key decision points in the bis process:

1. Registry Selection: Which TEL registry should track this credential?

   • Use existing registry for related credentials
   • Create new registry for different credential types or governance domains

2. Registrar Configuration: Which entities should serve as Registrars?

   • Number of Registrars (affects redundancy and availability)
   • Registrar threshold (minimum confirmations required)
   • Registrar identities (trust considerations)

3. Anchoring Strategy: When to anchor the TEL event to the KEL?

   • Immediate anchoring (most common)
   • Batched anchoring (multiple TEL events in one KEL event)
   • Delayed anchoring (for specific workflow requirements)

4. Public vs. Private: Should the credential be publicly discoverable?

   • Public credentials: TEL events may be widely distributed
   • Private credentials: May use blinded TEL or restricted Registrar access

Technical Requirements

Cryptographic Requirements

Digest Algorithms: The bis operation requires cryptographically strong digest algorithms:

• Minimum strength: 128 bits of cryptographic security
• Supported algorithms: Blake3-256, SHA3-256, Blake2b-256
• CESR encoding: All digests must be CESR-qualified with derivation codes

Signature Requirements:

• KEL events containing TEL anchoring seals must be signed by current authoritative keys
• Signature strength must match or exceed the digest strength
• Multi-sig credentials require threshold-satisficing signatures
• Signatures must be attached in CESR format

SAID Computation:

• Credential SAID must be computed over canonical serialization
• SAID field must be replaced with # characters of appropriate length during computation
• Final SAID must be embedded in the credential's d field

Timing Considerations

Sequence Ordering:

• TEL events must be processed in sequence number order
• Out-of-order events should be escrowed until dependencies are satisfied
• The bis event (sequence 0) must be the first event for a given credential

Timestamp Requirements:

• The dt field should reflect actual issuance time
• Timestamps should be in ISO 8601 format with timezone
• Clock skew between issuer and Registrars should be minimal
• Timestamps are informational, not used for ordering (sequence numbers provide ordering)

Anchoring Latency:

• TEL events should be anchored to KEL "soon" after creation
• Unanchored TEL events may not be considered authoritative
• Validators may reject credentials with unanchored issuance events
• Recommended: anchor within the same transaction or operation

Error Handling

Validation Failures:

If TEL event validation fails:

1. Structural errors: Reject malformed events immediately
2. Signature failures: Verify KEL event signatures; reject if invalid
3. Sequence errors: Escrow out-of-order events; process when dependencies arrive
4. Registry mismatches: Verify ri field matches expected registry; reject if incorrect

Registrar Unavailability:

If Registrars are unreachable:

1. Retry logic: Implement exponential backoff for transient failures
2. Threshold satisfaction: Ensure minimum number of Registrars confirm receipt
3. Escrow mechanisms: Queue events for later delivery if Registrars are offline
4. Monitoring: Alert on persistent Registrar failures

Duplicate Detection:

If duplicate bis events are detected:

1. SAID comparison: Events with identical credential SAIDs are duplicates
2. Sequence verification: Only sequence 0 is valid for issuance
3. Rejection: Reject duplicate issuance attempts
4. Logging: Record duplicate attempts for security monitoring

Recovery Procedures:

If bis operation fails mid-process:

1. Idempotency: Design operations to be safely retryable
2. State verification: Query Registrars to determine current state
3. Rollback: If partial state exists, may need to revoke and reissue
4. Audit trail: Maintain logs of all issuance attempts

Usage Patterns

Typical Scenarios

Scenario 1: vLEI Credential Issuance

In the GLEIF vLEI ecosystem:

1. A QVI (Qualified vLEI Issuer) issues a Legal Entity credential
2. The QVI creates the ACDC with Legal Entity attributes
3. The QVI performs bis operation to record issuance in their TEL registry
4. The Legal Entity receives the credential and can present it to verifiers
5. Verifiers query the TEL registry to confirm the credential is issued and not revoked

This pattern enables:

• Auditable credential issuance by authorized QVIs
• Real-time revocation checking by verifiers
• Compliance with vLEI governance framework requirements

Scenario 2: Supply Chain Credentials

In supply chain applications:

1. A manufacturer issues a product authenticity credential
2. The credential includes product identifiers and manufacturing details
3. bis operation records the credential in a public TEL registry
4. Downstream parties (distributors, retailers, consumers) can verify authenticity
5. If a product is recalled, the manufacturer can revoke the credential via brv

This pattern enables:

• Product authentication throughout the supply chain
• Counterfeit detection
• Recall management

Scenario 3: Educational Credentials

In educational contexts:

1. A university issues a degree credential to a graduate
2. The credential includes degree details, graduation date, and student information
3. bis operation records issuance in the university's TEL registry
4. Employers can verify the credential by checking the TEL registry
5. If the degree is revoked (e.g., academic misconduct), the university uses brv

This pattern enables:

• Verifiable academic credentials
• Reduced credential fraud
• Streamlined background verification

Best Practices

Registry Management:

• Use separate TEL registries for different credential types or governance domains
• Configure appropriate Registrar thresholds (typically 2 of 3 or 3 of 5)
• Select geographically distributed Registrars for resilience
• Monitor Registrar health and performance

Credential Design:

• Include sufficient information in the credential for verification
• Use schema SAIDs to ensure credential structure consistency
• Consider privacy implications of public TEL registries
• Implement graduated disclosure for sensitive attributes

Operational Security:

• Protect issuer private keys with appropriate key management
• Use hardware security modules (HSMs) for high-value credentials
• Implement multi-signature controls for critical issuance operations
• Maintain audit logs of all issuance activities

Performance Optimization:

• Batch multiple TEL events in a single KEL anchoring event when possible
• Use asynchronous processing for Registrar distribution
• Implement caching for frequently queried credential states
• Monitor and optimize TEL query performance

Integration Considerations

IPEX Protocol Integration:

The bis operation integrates with IPEX (Issuance and Presentation Exchange):

1. Issuer performs bis to record credential issuance
2. Issuer sends IPEX grant message to issuee with credential
3. Issuee admits the credential and stores it locally
4. Issuee can later present the credential via IPEX apply/offer messages
5. Verifiers check TEL registry during presentation verification

Witness Coordination:

The KEL events containing TEL anchoring seals must be witnessed:

1. Issuer creates interaction event with TEL seal
2. Event is sent to configured witnesses
3. Witnesses provide receipts confirming observation
4. Receipts are collected and attached to the event
5. Fully receipted event provides strong duplicity detection

Watcher Networks:

Watchers can monitor TEL registries:

1. Watchers subscribe to Registrar event streams
2. Watchers maintain independent copies of TEL state
3. Watchers can detect inconsistencies between Registrars
4. Watchers provide additional verification for high-stakes credentials

DID Integration:

For did:keri and did:webs methods:

1. The issuer AID can be expressed as a DID
2. The credential can reference the issuer DID
3. DID resolution provides access to the issuer's KEL
4. TEL registry information can be included in DID documents
5. Verifiers can use standard DID resolution to access TEL data

Implementation Guidance

Implementing bis operations requires careful attention to:

Data Structures: Proper serialization of TEL events, KEL events, and ACDC credentials using CESR encoding.

State Management: Maintaining consistent state across issuer, Registrars, and validators.

Network Communication: Reliable delivery of events to Registrars with appropriate retry logic.

Cryptographic Operations: Correct implementation of digest computation, signature generation, and verification.

Error Handling: Robust handling of validation failures, network errors, and edge cases.

Testing: Comprehensive testing of issuance workflows, including failure scenarios and recovery procedures.

The bis operation is fundamental to KERI's verifiable credential lifecycle management, providing the cryptographic foundation for trustworthy, revocable credentials in decentralized systems.