The Cryptographic Bridge Between Digital Identity and Physical Matter.
The Universal Object Registry and Attestation (UORA) protocol solves a fundamental problem in decentralized identity: the physical binding problem. A digital attestation chain proves the provenance of a DID, but not that a specific physical artifact is its true referent.
UORA enables you to cryptographically bind a physical object to its Decentralized Identifier (DID). It scales from simple tamper-evident labels to hardware-backed, physically unclonable functions (PUFs) with continuous environmental monitoring.
Why UORA?
- ❌ Without UORA: A counterfeit pharmaceutical bottle passes all digital checks because it cloned a QR code.
- ✅ With UORA: Verification cryptographically proves that the unique, unclonable hardware inside the genuine bottle is physically present.
This repository contains the normative specification for the Secure Physical Binding sub-protocol.
- Latest Draft: https://w3id.org/uora/spec/core/v1.0
- Editor: Amir Hameed Mir (Sirraya Labs)
- Status: W3C Community Group Draft (CG-DRAFT)
The protocol operates under a formally specified attacker model, requires no trusted transport channel, and defines four Binding Assurance Levels (BAL):
| Level | Mechanism | Attacker Resistance |
|---|---|---|
| BAL-1 | Tamper-Evident Carrier & Visual ID | A0 (Network) |
| BAL-2 | Secure Element with Asymmetric Crypto | A0-A2 (Physical Access) |
| BAL-3 | Physically Unclonable Function (PUF) | A0-A3 (Fab-level attacks) |
| BAL-4 | PUF + Continuous Environmental Attestation | A0-A5 (Including RF relay) |
Start with the Introduction and Binding Assurance Levels to understand the threat model and choose the right BAL for your use case.
UORA is cryptographically agnostic but provides three core profiles:
- Profile A (Ed25519): For high-performance, modern constrained devices.
- Profile B (ECDSA P-256): For FIPS-regulated environments.
- Profile C (AES-128-CMAC): Deprecated. For backward compatibility in closed legacy systems only.
Clone the repo and integrate the protocol. Use our Conformance Test Suite (CTS) to validate your implementation.
git clone https://github.com/uora-wg/core.git
cd core
# Conformance tests available at:
# https://w3id.org/uora/conformance/binding/v1- [Appendix A: PUF Interface Descriptor (PID)]: The standard schema to make any PUF hardware interoperable.
- [Appendix B: Trust Framework Profile 1 (TFP-1)]: The baseline governance model you can adopt.
- [Appendix C: Proximity-Bound Authenticated Channel (PBAC)]: The cryptographic solution to relay attacks for BAL-4.
This is a community-driven specification. Your insights on security, implementation, and use cases are critical.
- 💡 Propose Changes: Open an issue or pull request against the
mainbranch. - 🐛 Report Bugs: Use our issue tracker with a clear description and proposed fix.
- 📣 Share Feedback: Join the W3C Community Group discussions.
- 🔒 Security Disclosures: DO NOT open a public issue. See our
SECURITY.mdfor responsible disclosure.
- Discuss: Start a conversation in GitHub Issues to align on scope.
- Develop: Make your changes in a feature branch.
- Validate: Ensure it passes all linters and the Conformance Test Suite.
- Review: Submit a PR for review by the editors. All contributions are licensed under the W3C Software and Document License.
.
├── index.html # The normative ReSpec source
├── diagrams/ # Sequence & architectural diagrams
│ ├── enrollment.mmd
│ └── challenge.mmd
├── profiles/ # Cryptographic profile definitions
├── conformance/ # Test vectors and CTS
├── examples/ # Sample enrollment & verification payloads
└── README.md # You are here
- W3C Group: cg/uora
- Matrix Chat:
#uora-wg:matrix.org(for informal dev chat) - Mailing List:
public-uora@w3.org
All documents in this repository are governed by the W3C Software and Document License.
Copyright © 2025 UORA Community Group.