JLINC
Identity Protocol
Company
Details
License Mixed: jlinx is Apache-2.0; jlinc-did-client and jlinc-jwt are MIT; jlinc-node and didserver state no licence; the company's on-prem product is licensed under SSPLv1
Dev Status 🧪 Alpha
Dev Status Detail Alpha (protocol 'Version 10', undated; reference code is small and last updated between 2023 and 2025; no releases listed; the company site describes a commercial product)
Owner JLINC Inc (copyright line on the company site); the DID method specification is copyrighted to Portable Data Corporation; how the two relate is not stated
Governing Body Company-controlled (JLINC; no board or governance body is described beyond officer titles)
Country Not stated by the project (the company describes a team based in the Bay Area)
Stack Reference implementations in JavaScript/Node.js (jlinc-node) and Go with PostgreSQL (didserver); Ed25519 keys; EdDSA JWT signatures; JSON Canonicalization (RFC 8785)
Funding Not stated by the project.
Last Investigated Nov 12, 2026
Identity Protocol Attributes
Origins A data-sharing agreement protocol. FedID is a separate identity system, a different technology: its own pages describe it as 'FedID from JLINC' and say its DID Document 'is based on the JLINC format for decentralized identifiers', using did:jlinc DIDs
Database The Go reference DID server (didserver) uses PostgreSQL 9.6 or later; the protocol itself does not require a database
Query Language N/A: a signed-message protocol; no query language
Data Formats JSON-LD agreement and audit records, EdDSA JWTs (RFC 7519), JSON Canonicalization (RFC 8785); optional compatibility with W3C Verifiable Credentials 2.0
Mobile Support Not stated by the project.
Web Support Not stated by the project.
Native Apps None stated for the protocol
Terms Mixed code licences (Apache-2.0, MIT, some unstated); the company's on-prem product is licensed under SSPLv1; commercial terms are not published
Funds Not stated by the project.
Based On W3C DID Core, JSON-LD 1.1, JWS and JWT (RFC 7515 and 7519), JSON Canonicalization (RFC 8785); the DID method draws on ideas from ActivityPub, did:web and KERI
Permissions Mixed: jlinx Apache-2.0; jlinc-did-client and jlinc-jwt MIT; jlinc-node and didserver state no licence; on-prem product under SSPLv1
Authentication & Identity Agreements must be signed with a private key that represents the parties' DIDs; the signing key should be controlled by the end user and may be delegated to an agent; the DID document can list a login service
Storage Model Each party keeps its own signed agreement record, and a signed hash of it goes to an audit record; audit records can be kept on designated archive servers
Interoperability Medium: W3C DID Core, a W3C-compatible option for verifiable credentials, and integrations the company lists (AuthZEN, LangChain, vCon)
Data Portability Not stated by the project.
Governance & Decision Making Company-controlled; the protocol page lists its authors and no standards process or change-control body is described
Protocol Maturity / Standardization Company specification (protocol Version 10, undated; DID method specification version 2, 10 January 2025); not submitted to a standards body
Identity Standards W3C DID Core; the JLINC DID method specification (did:jlinc, version 2); JSON-LD 1.1; EdDSA JWT; optional W3C Verifiable Credentials Data Model 2.0 compatibility
Identity Standards - List
DID Methods Supported did:jlinc (syntax did:jlinc:host:id, where the id is derived from a SHA-256 hash of the inception controller's public key and the recovery hash); the protocol's own examples use did:service, which no fetched source defines
Key Management Ed25519 signing and controller keys; private keys must be held securely and never sent over the network; recovery keys are to be kept offline until needed; key rotation uses the recovery key
Credential Types Signed agreements (Verifiable Contractual Agreements) and signed audit records; an optional mapping to W3C Verifiable Credentials
Credential Types - List
Verification Method Signatures on agreements verified against the parties' DID documents; the audit record holds a signed hash of the agreed record rather than a formal zero-knowledge proof
Privacy Features The DID method recommends a new pair-wise DID per relationship; audit records are designed to hold no sensitive or identifiable data
Authentication Methods DID-based signatures; the DID document can list a login service; the company site cites AuthZEN for fine-grained access control
Revocation Mechanism A DID can be deactivated (irreversible) and keys rotated with the recovery key; the protocol itself has no revocation section
Agent Types Supported People and services; a key may be owned by an agent when delegated; the company site mentions LangChain and vCon integrations
Wallet/Client Types Not stated by the project; client libraries are published for JavaScript (jlinc-did-client, jlinc-jwt, jlinc-zcap, did-web-auth)
Recovery Mechanisms A recovery key (held offline) authorizes key rotation; its hash is part of the DID
Compliance / Regulations The company claims support for SOX, HIPAA and GAAP and legally admissible compliance records; GDPR is not stated on the pages read
Credential Exchange Protocols The JLINC protocol (signed agreement and audit-record exchange between parties); an optional Verifiable Credentials mapping
Trust Framework Trust rests on the parties' signed agreements and the audit trail of hashes; no formal trust framework is stated
Cost Model Not stated by the project; the company offers a commercial on-prem product and hosted services
Censorship Resistance Not stated by the project.
Relationships
How this tool connects to other tools and organizations, from relationships reviewed by the OpenHaven data steward. They describe how projects connect, not how good they are.