Integrate business relationships
Model business relationships directly in your authorization model and implement workflows such as delegation and group authorization in a seamless and straightforward way.
Welcome to ExcID
Your Cyber Resilience Partner
Solutions
Solutions built for resilience, interoperability, and operational control
Each solution is designed around practical deployment needs: clear trust boundaries, open standards, privacy-preserving flows, and integration with existing systems.
Software supply chain
Make software artifacts verifiable without uploading them
STaaS is ExcID's free, open-source software transparency service for signing artifacts and recording signature information in a public, auditable registry.
Teams can authenticate, select a file locally, receive a short-lived certificate bound to their identity, and generate signatures using one-time keys. Signature information is recorded for auditability, while artifact contents remain private.
- Built around Sigstore components including Fulcio-style certificates, Rekor transparency records, and Cosign verification.
- Useful for binaries, documents, images, release artifacts, and evidence packages.
- Web-based access, as well as REST API that can be accessed by CI/CD processes.
Access control
Improved access control for decentralized HTTP services
State of the art access control with fine-grained trust management, business workflow integration, and straightforward integration with legacy systems.
In a nutshell
ExcID integrates OpenFGA, an open source implementation of Zanzibar, which is Google's authorization system protecting YouTube, Drive, and other Google services.
ExcID's solution allows administrators to determine the access rights of their users and issue authorizations in the form of Verifiable Credentials. Users can store their authorizations in their wallet of choice, including ExcID's own web-based wallet, and use that wallet to gain access to protected resources in a secure and privacy-preserving way. The solution is based on ongoing work by W3C, IETF, and the OpenID Foundation.
Key properties
Transitive access rights
Organize access control objects using relationships, such as Smart Lamp1 is located in Smart Home1, and parameterize authorization rules so a user who can access Smart Home1 can access anything located in it.
Management and interoperability
Revoke any authorization instantly. The policy decision point can check revocation status with every request, enable continuous authorization for zero-trust systems, and let businesses federate protected resources in a controlled and secure way.
Learn more
Relation-based access control using Verifiable Credentials
Read how this system is used for protecting digital twins.
Decentralized identity
did:self decentralized identifiers without registry dependency
A method for Decentralized Identifiers that does not require a secure registry, such as a blockchain or web server, and still allows private key rotation.
About
Decentralized Identifiers (DIDs) are a W3C recommendation that enables verifiable, decentralized digital identity. DIDs are investigated for self-sovereign digital identities, improving supply chain security, and Web5-style applications.
Current W3C recommendations define a framework implemented by many DID methods. Existing DID methods either require a trusted registry where auxiliary information is stored, or they do not support private key rotation. did:self removes the need for a trusted registry while supporting advanced operations such as private key rotation, DID co-ownership, and DID delegation.
Use cases
IoT group communication
IoT devices belonging to the same group, such as all temperature sensors of a building, can be configured with the same DID identifier. Group membership can be proved while each device keeps its own private key that can be rotated to protect the group from key breaches.
Data identification
A did:self identifier can identify content items or service endpoints, support secure delegation to third-party providers such as CDNs, and enable self-verifiable content authenticity without a Trusted Third Party.
Device handover
A user can use a did:self identifier with multiple devices while limiting the validity period of keys on less secure devices, such as allowing a mobile phone to use the identifier only for the duration of a business trip.
Specifications
Read the did:self specifications and learn how to construct and protect a did:self identifier.
View specifications on GitHubDevelop
Get started with the Python implementation of did:self. Create, manage, and verify did:self identifiers.
View implementation on GitHub