DID Attributes
When to use
You want to attach a small piece of structured data to your DID — e.g. a service URL, a name, a hash — without modifying the DID Document directly. This mirrors the ERC-1056 attribute mechanism: signed key/value pairs anchored on chain.
Before you begin
- You own the DID.
- The attribute name is short (≤32 bytes) and meaningful.
Steps
- Open
/dids/:didand scroll to Attributes. - Click Set attribute.
- Enter:
- Name — e.g.
did/svc/HubService,did/auth/email. - Value — string or hex-encoded bytes.
- Validity — seconds.
- Name — e.g.
- Save. Calls
POST /api/v1/dids/{did}/attributes(did.go:369).
API & SDK
Verify
Resolve the DID; the attribute is exposed via the didDocumentMetadata.attributes array (or whatever the resolver returns — see §3.1.9).
Troubleshooting
If a value isn’t appearing, the most common cause is a stale cache. Force a re-resolve with:
3.1.9. Universal DID Resolver Tool ##### When to use
You need to fetch the DID Document for any DID — yours, someone else’s, or a DID from a different method entirely. The universal resolver is the public, no-auth endpoint that does this.
Before you begin
Nothing required. The endpoint is unauthenticated.
Steps
- Open the DID Resolver page in the portal (
/tools/did-resolver) — or just call the endpoint directly. - Paste the DID into the input field.
- Click Resolve.
- The portal calls
GET /api/v1/dids/resolve/{did}(did.go:29, registered atrouter.go:74).
Supported methods
API
Response shape (per W3C DID Resolution):
Verify
Compare the returned key fingerprint against an out-of-band channel (e.g., the issuer’s website, a printed business card). DID Documents are public, but their binding to a real-world entity is your responsibility.