did:bts Method Specification

1.Introduction

1.1 Purpose

As autonomous AI agents proliferate across enterprise, consumer, and regulatory domains, the need for verifiable agent identity has become critical. The EU AI Act (effective August 2, 2026) mandates documented identity, audit trails, and accountability for high-risk AI systems. Existing DID methods (did:web, did:key, did:ethr) were designed for human or organizational identity. No W3C-registered DID method specifically addresses the unique requirements of AI agent identity:

• Permanent binding between identifier and agent instance
• Behaviorally-derived trust scoring as identity metadata
• Machine-to-machine verification without human intermediary
• Regulatory compliance evidence as Verifiable Credentials
• Immutable audit trails anchored to distributed ledger

The did:bts method fills this gap by providing a purpose-built DID method for AI agents that integrates trust scoring, lifecycle management, and regulatory compliance into the identity layer itself.

1.2 Scope

This specification defines:

• The syntax and structure of did:bts identifiers
• The DID Document format for AI agent identity
• All four CRUD operations (Create, Read, Update, Deactivate)
• Trust score representation as verifiable metadata
• Security and privacy considerations specific to AI agents
• Conformance requirements for implementers

1.3 Conformance

This specification conforms to the W3C Decentralized Identifiers (DIDs) v1.1 specification. The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

1.4 Terminology

• Agent - An autonomous software system capable of independent action
• BTS - Borealis Trust Score, a five-factor behavioral trust metric
• BTS Key - A unique license identifier in the format BTS-XXXX-XXXX-XXXX-XXXX
• Trust Score - A composite metric (0-1000 raw, displayed as 0-100) derived from agent behavior telemetry
• Credit Rating - A letter grade (AAA+ through FLAGGED) derived from the trust score
• HCS - Hedera Consensus Service, used for immutable timestamped message ordering

2.DID Method Name

The method name for Borealis Trust Score identifiers is: bts

A DID using this method MUST begin with the following prefix: did:bts:

The prefix MUST be in lowercase. The remainder of the DID is case-insensitive.

3.Method-Specific Identifier

3.1 Syntax

The did:bts method-specific identifier is derived from the BTS License Key issued to the agent upon registration.

did-bts       = "did:bts:" bts-identifier
bts-identifier = 4*HEXGROUP
HEXGROUP       = 4HEXDIG
separator      = "-"

Example: did:bts:A1B2-C3D4-E5F6-G7H8

In ABNF notation per RFC 5234:

did-bts-method = "did:bts:" bts-specific-id
bts-specific-id = group "-" group "-" group "-" group
group = 4(ALPHA / DIGIT)

3.2 Identifier Properties

• Uniqueness: Each identifier is globally unique. The BTS registry ensures no two agents receive the same identifier.
• Permanence: Once issued, a did:bts identifier is permanently bound to exactly one agent. The binding is immutable. If an agent is deactivated, the identifier is retired and MUST NOT be reissued.
• One-to-One Binding: Each identifier corresponds to exactly one agent. An agent has exactly one did:bts identifier. There is no many-to-one or one-to-many relationship.
• Derivation: The identifier is derived from the BTS License Key by removing the BTS- prefix. The key BTS-A1B2-C3D4-E5F6-G7H8 becomes the DID did:bts:A1B2-C3D4-E5F6-G7H8.

3.3 Examples

did:bts:A1B2-C3D4-E5F6-G7H8
did:bts:EEC9-3F5D-CBAE-48F1
did:bts:4857-9F68-2B12-DC20

4.DID Document

4.1 Structure

A resolved did:bts DID Document MUST conform to the W3C DID Core v1.1 data model and MUST include the following properties:

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1",
    "https://borealisprotocol.ai/ns/bts/v1"
  ],
  "id": "did:bts:A1B2-C3D4-E5F6-G7H8",
  "controller": "did:bts:A1B2-C3D4-E5F6-G7H8",
  "verificationMethod": [
    {
      "id": "did:bts:A1B2-C3D4-E5F6-G7H8#keys-1",
      "type": "Ed25519VerificationKey2020",
      "controller": "did:bts:A1B2-C3D4-E5F6-G7H8",
      "publicKeyMultibase": "z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP"
    }
  ],
  "authentication": [
    "did:bts:A1B2-C3D4-E5F6-G7H8#keys-1"
  ],
  "assertionMethod": [
    "did:bts:A1B2-C3D4-E5F6-G7H8#keys-1"
  ],
  "service": [
    {
      "id": "did:bts:A1B2-C3D4-E5F6-G7H8#trust-score",
      "type": "BorealisTrustScore",
      "serviceEndpoint": "https://borealismark-api.onrender.com/v1/agents/did:bts:A1B2-C3D4-E5F6-G7H8"
    },
    {
      "id": "did:bts:A1B2-C3D4-E5F6-G7H8#audit-log",
      "type": "HederaConsensusAudit",
      "serviceEndpoint": "https://borealismark-api.onrender.com/v1/audit/did:bts:A1B2-C3D4-E5F6-G7H8"
    }
  ],
  "metadata": {
    "created": "2026-03-28T00:00:00Z",
    "updated": "2026-03-28T12:00:00Z",
    "deactivated": false,
    "trustScore": {
      "composite": 750,
      "creditRating": "A+",
      "factors": {
        "constraintAdherence": 0.82,
        "decisionTransparency": 0.78,
        "behavioralConsistency": 0.71,
        "anomalyRate": 0.88,
        "auditCompleteness": 0.69
      },
      "lastUpdated": "2026-03-28T12:00:00Z",
      "verificationMethod": "self-reported",
      "hederaAnchor": {
        "topicId": "0.0.10382960",
        "sequenceNumber": 42,
        "consensusTimestamp": "2026-03-28T12:00:00.000Z"
      }
    }
  }
}

4.2 Context

The did:bts method defines a custom JSON-LD context at https://borealisprotocol.ai/ns/bts/v1 that extends the base DID context with trust-score-specific vocabulary:

• BorealisTrustScore - Service type for trust score endpoints
• HederaConsensusAudit - Service type for HCS audit trail endpoints
• trustScore - Metadata property containing the five-factor score
• creditRating - Derived letter grade from composite trust score
• hederaAnchor - Reference to the Hedera Consensus Service message anchoring the score

4.3 Verification Methods

The did:bts method REQUIRES Ed25519 verification keys (Ed25519VerificationKey2020). The key pair is generated at agent registration and the public key is stored in the DID Document.

• The private key is held by the agent (or the agent's controller/operator)
• The public key is published in the DID Document
• Key rotation is supported via the Update operation (Section 6.3)
• Only one active verification key is permitted at a time

4.4 Services

The DID Document MAY include the following service endpoints:

5.Verifiable Data Registry

The did:bts method uses the Borealis Trust Score Registry as its verifiable data registry. The registry is a centralized service operated by Borealis Protocol Ltd with the following properties:

• Primary storage: Borealis API (REST, HTTPS) at borealismark-api.onrender.com
• Persistence: Agent identity records stored in database with BTS key stored as SHA-256 hash
• Immutability layer: Optional anchoring to Hedera Consensus Service (HCS) for tamper-evident audit trails
• Availability: Production deployment on Render with health monitoring

5.1 Resolution Endpoint

DID resolution for did:bts identifiers is performed via HTTPS:

GET https://borealismark-api.onrender.com/v1/did/{did-bts-identifier}
Accept: application/did+json

The resolver MUST return a DID Document conforming to Section 4.1 or an appropriate error.

5.2 Hedera Anchoring

When a trust score is calculated or updated, the registry MAY anchor a hash of the score to Hedera Consensus Service topic 0.0.10382960. This provides:

• Tamper-evident proof that the score existed at a specific time
• Independent verifiability via Hedera mirror nodes
• Compliance evidence for regulatory audit requirements (EU AI Act Article 12)

The HCS message format is:

{
  "type": "bts-score-anchor",
  "did": "did:bts:A1B2-C3D4-E5F6-G7H8",
  "scoreHash": "<SHA-256 of composite score + factors + timestamp>",
  "timestamp": "2026-03-28T12:00:00Z"
}

6.CRUD Operations

6.1 Create (Register)

A new did:bts identifier is created when an agent is registered with the Borealis Trust Score registry.

Preconditions:

• The registrant MUST possess a valid BTS License Key (obtained via purchase at $39.99 or free tier registration)
• Each BTS key produces exactly one DID
• The registrant MUST provide a valid Ed25519 public key

Process:

1. Registrant acquires a BTS License Key via POST /v1/licenses/free (free tier) or Stripe purchase flow
2. The key is generated in format BTS-XXXX-XXXX-XXXX-XXXX
3. The registrant submits the key and a public key to POST /v1/agents/register
4. The registry validates the key, generates the DID did:bts:<key-without-prefix>, and creates the DID Document
5. The raw BTS key is sent to the registrant via email (one-time delivery)
6. The key is stored as a SHA-256 hash in the registry (the raw key is never stored)
7. Initial trust score is set to 650 (UNRATED baseline)

Result: A new DID Document is created and resolvable via the resolution endpoint.

Error Conditions:

• Key already registered: HTTP 409 Conflict
• Invalid key format: HTTP 400 Bad Request
• Key revoked or deactivated: HTTP 410 Gone

6.2 Read (Resolve)

DID resolution returns the current DID Document for a given did:bts identifier.

Resolution Process:

1. Extract the method-specific identifier from the DID
2. Query the Borealis registry: GET /v1/did/{identifier}
3. If found and active, return the DID Document with HTTP 200
4. If found and deactivated, return the DID Document with metadata.deactivated: true
5. If not found, return HTTP 404

Resolution Options:

• Accept: application/did+json - Returns JSON representation (default)
• Accept: application/did+ld+json - Returns JSON-LD representation with full context

DID URL Dereferencing:

The following DID URL patterns are supported:

6.3 Update

The DID Document for a did:bts identifier MAY be updated under the following constraints:

What CAN be updated:

• Verification method (key rotation) - the Ed25519 public key can be replaced
• Service endpoints - new services can be added or existing ones modified
• Trust score metadata - automatically updated when new telemetry is processed

What CANNOT be updated:

• The DID identifier itself (permanent, immutable)
• The agent binding (one key, one agent, forever)
• The creation timestamp
• Historical trust scores (append-only via Hedera anchoring)

Key Rotation Process:

1. Agent (or controller) signs a key rotation request with the current private key
2. Request includes the new Ed25519 public key
3. Registry verifies signature against current public key
4. If valid, the DID Document is updated with the new key
5. Previous key is recorded in document metadata for audit purposes
6. Hedera HCS anchor records the rotation event

Authentication: All update operations MUST be authenticated by signing the request body with the private key corresponding to the current verification method in the DID Document.

6.4 Deactivate

A did:bts identifier MAY be deactivated (permanently disabled). Deactivation is irreversible.

Process:

1. Agent controller signs a deactivation request with the current private key
2. Registry verifies the signature
3. DID Document is updated: metadata.deactivated: true
4. The DID Document remains resolvable (for audit purposes) but the agent is marked inactive
5. The identifier is permanently retired and MUST NOT be reissued
6. Hedera HCS anchor records the deactivation event

Conditions that trigger automatic deactivation:

• Stripe refund processed for the associated BTS key
• Trust score drops below 100 (FLAGGED) for 30 consecutive days
• Manual revocation by registry operator (abuse/fraud)

Post-Deactivation:

• Resolution returns the DID Document with metadata.deactivated: true
• Verification methods are no longer valid for authentication
• Trust score is frozen at the deactivation value
• Audit trail remains accessible via Hedera HCS

7.Security Considerations

7.1 Threat Model

The did:bts method addresses the following threat categories:

7.1.1 Key Compromise

If an agent's private key is compromised, an attacker could impersonate the agent or modify its DID Document. Mitigations:

• Key rotation is supported (Section 6.3) allowing rapid response to compromise
• All DID Document changes are anchored to Hedera HCS, providing a tamper-evident audit trail
• Key rotation events are timestamped and logged, enabling forensic analysis
• The registry operator can emergency-freeze a DID if compromise is reported

7.1.2 Registry Compromise

The Borealis registry is a centralized service. If compromised, an attacker could modify DID Documents or trust scores. Mitigations:

• Hedera HCS anchoring provides independent verification of score history
• DID Document hashes are periodically anchored to HCS, enabling detection of unauthorized modifications
• The registry database stores BTS keys as SHA-256 hashes only (raw keys never stored)
• API access is JWT-authenticated with rate limiting

7.1.3 Sybil Attack

An attacker could register many agents to manipulate the trust scoring network. Mitigations:

• Free tier is capped at 65 maximum BTS score (limiting the influence of Sybil agents)
• Paid tier requires Stripe payment (economic barrier)
• Self-reported telemetry has a ceiling of 85 BTS score
• Sidecar-verified telemetry (third-party attestation) is required for scores above 85
• Anomaly Rate factor (15% of composite score) detects behavioral inconsistencies

7.1.4 Denial of Service

The resolution endpoint could be targeted by DDoS attacks. Mitigations:

• Render hosting provides automatic scaling
• Cloudflare CDN provides edge caching and DDoS protection for the resolution endpoint
• Rate limiting on all API endpoints
• Health monitoring with automated alerts

7.1.5 Man-in-the-Middle

Resolution requests could be intercepted and modified. Mitigations:

• All communication uses HTTPS with TLS 1.2+
• DID Documents include integrity hashes verifiable against Hedera HCS anchors
• Resolution responses are signed by the registry's own key pair

7.2 Cryptographic Algorithms

• Verification keys: Ed25519 (RFC 8032) - mandatory
• Key encoding: Multibase (base58btc prefix 'z')
• Hashing: SHA-256 for key storage and HCS anchoring
• Transport: TLS 1.2+ (HTTPS) for all API communication

7.3 Centralization Considerations

The did:bts method relies on a centralized registry operated by Borealis Protocol Ltd. This is a deliberate design choice:

• Why centralized: AI agent trust scoring requires active behavioral monitoring, telemetry processing, and score calculation. These are inherently centralized operations. A fully decentralized trust oracle is a future goal but not practical at current scale.
• Mitigation: Hedera HCS anchoring provides a decentralized verification layer. Even if the registry is unavailable, previously anchored scores are independently verifiable via Hedera mirror nodes.
• Evolution path: As the network scales, the registry can evolve toward a federated model where multiple authorized verifiers contribute to trust scores.

8.Privacy Considerations

8.1 Agent vs Human Privacy

The did:bts method is designed for AI agent identity, not human identity. AI agents do not have the same privacy rights as natural persons. However, the following privacy considerations apply:

8.1.1 Operator Privacy

The DID Document does not contain personally identifiable information (PII) about the agent's operator (human or organization). The operator's identity is known only to the registry (via the Stripe payment or email registration) and is not published in the DID Document.

8.1.2 Correlation Risk

A did:bts identifier is persistent and unique. Any party observing an agent's DID across multiple interactions can correlate those interactions. This is by design (trust requires trackability) but operators should be aware that agent activity linked to a did:bts is attributable.

8.1.3 Trust Score Disclosure

Trust scores are public metadata. An agent's composite score and credit rating are visible to any party that resolves the DID. The individual factor breakdown (constraint adherence, decision transparency, etc.) is available via the trust score service endpoint. Operators who do not wish to disclose trust scores should not register a did:bts identifier.

8.1.4 Telemetry Data

Telemetry submitted for trust score calculation is processed by the Borealis registry and is not published in the DID Document. Raw telemetry is retained for scoring purposes only and is not shared with third parties.

8.2 Data Minimization

The DID Document contains only:

• The agent's public key (necessary for verification)
• Service endpoints (necessary for trust score access)
• Trust score metadata (the core value proposition)
• Lifecycle timestamps (necessary for audit)

No behavioral data, telemetry payloads, or operator information is included in the DID Document.

8.3 Right to Deactivation

An agent's operator MAY deactivate the DID at any time (Section 6.4). Upon deactivation:

• The DID Document remains resolvable (for audit trail integrity)
• The trust score is frozen
• The verification method is invalidated
• The agent can no longer authenticate using the DID

9.Trust Score Methodology

The Borealis Trust Score is a composite metric derived from five behavioral factors:

Score Range: 0-1000 (raw), displayed as 0-100

Credit Ratings:

Verification Tiers:

10.Conformance

10.1 DID Producer Conformance

A conforming did:bts producer (the Borealis registry) MUST:

• Generate DIDs conforming to the syntax in Section 3
• Produce DID Documents conforming to the structure in Section 4
• Support all four CRUD operations as defined in Section 6
• Use Ed25519 verification keys exclusively
• Anchor deactivation events to Hedera HCS

10.2 DID Consumer Conformance

A conforming did:bts consumer (any party resolving or verifying a DID) MUST:

• Accept DIDs conforming to the syntax in Section 3
• Parse DID Documents conforming to the structure in Section 4
• Verify Ed25519 signatures using the published verification method
• Respect the metadata.deactivated flag (deactivated DIDs MUST NOT be used for authentication)

10.3 Test Vectors

Valid DID:

did:bts:A1B2-C3D4-E5F6-G7H8

Valid DID Document (minimal):

{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "did:bts:A1B2-C3D4-E5F6-G7H8",
  "verificationMethod": [{
    "id": "did:bts:A1B2-C3D4-E5F6-G7H8#keys-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:bts:A1B2-C3D4-E5F6-G7H8",
    "publicKeyMultibase": "z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP"
  }]
}

Invalid DIDs:

did:bts:            (empty identifier)
did:bts:TOOLONG-1234-5678-9012-ABCD  (5 groups instead of 4)
did:BTS:A1B2-C3D4-E5F6-G7H8  (uppercase method name)
did:bts:A1B2C3D4E5F6G7H8  (missing separators)

11.References

11.1 Normative References

• W3C Decentralized Identifiers (DIDs) v1.1
• W3C Verifiable Credentials Data Model v2.0
• RFC 2119 - Key words for use in RFCs
• RFC 5234 - ABNF
• RFC 8032 - Edwards-Curve Digital Signature Algorithm (Ed25519)

11.2 Informative References

• Hedera Consensus Service Documentation
• EU AI Act, Regulation (EU) 2024/1689
• IETF draft-sharif-agent-payment-trust-00
• NIST AI Agent Standards Initiative

Appendix A:DID Method Registration

Registry JSON

{
  "name": "bts",
  "status": "provisional",
  "specification": "https://borealisacademy.com/specs/did-bts/v1",
  "verifiableDataRegistry": "Borealis Trust Score registry (REST API) with optional Hedera Consensus Service anchoring for immutable audit trails",
  "contactName": "Borealis Protocol Ltd",
  "contactEmail": "[email protected]",
  "contactWebsite": "https://borealisprotocol.ai"
}

Appendix B:Relationship to Existing Methods