Trust & Delegation

Trust model

Traditional identity systems use centralized trust (a CA or government registry says “this issuer is trusted”). BaseID adds a decentralized trust layer — anyone can attest to the reputation of any DID, and trust scores are computed from the graph of attestations.

Reputation attestations

An attestation is a signed claim that one DID makes about another:

Issuer DID ──attestation──→ Subject DID
  "I attest that did:key:z6MkAlice has a
   score of 85/100 in the 'identity' domain"

Attestation fields

Field	Description
`issuer`	DID of the attester
`subject`	DID being attested
`domain`	Trust domain (e.g., “identity”, “education”, “healthcare”)
`score`	0-100 reputation score
`weight`	0.0-1.0 attester confidence/authority
`evidence`	References supporting the attestation
`expires_at`	Optional expiry

Trust graph

Attestations form a directed graph where nodes are DIDs and edges are attestations:

Government ──(95, identity)──→ University
     │                              │
     └──(90, identity)──→ Alice ←──(80, education)──┘
                            │
                            └──(70, identity)──→ Bob

Graph operations

Operation	Description
Add attestation	Create an edge in the graph
Query attestations	List all attestations for a subject DID
Compute score	Calculate aggregate trust score in a domain
Find path	Discover trust chains between two DIDs

Scoring algorithms

Three algorithms for computing trust scores from the graph:

Direct Only

Simple average of direct attestations in a domain. Fast, but ignores transitive trust.

Score = average(attestations for subject in domain)

Transitive Trust

PageRank-inspired algorithm that propagates trust through the graph. An attestation from a highly-trusted DID carries more weight.

Score = damped_iteration(graph, subject, domain)
  damping = 0.85, iterations = 10

Reputation Weighted

Depth-limited traversal where each hop’s score is weighted by the attester’s own reputation.

Score = weighted_traversal(graph, subject, domain, depth=3)

Credential delegation

Delegation allows a credential holder to grant scoped access to another party — enabling use cases like a parent presenting on behalf of a child, or an employee acting on behalf of an organization.

Delegation model

Delegator ──DelegationToken──→ Delegate
  "I grant did:key:z6MkAssistant access to
   my CanadianDigitalID's givenName and province
   fields, for the purpose of 'booking', valid
   for 24 hours, max re-delegation depth 0"

Scope constraints

Constraint	Description
`purpose`	Why the delegation is granted
`allowed_claims`	Which credential claims the delegate can access
`max_depth`	How many times the delegate can re-delegate (0 = no re-delegation)
`valid_until`	Expiry timestamp

Delegation chains

Delegations can be chained (if max_depth > 0):

Original Holder → Delegate A → Delegate B
  (depth 0)        (depth 1)    (depth 2)

Each link in the chain narrows the scope — a delegate cannot grant more access than they received.

Verification

Verifying a delegated presentation checks:

Chain continuity (each link references the previous)
Scope compliance (claims are within allowed set)
Depth limit (chain length ≤ max_depth)
Signature validity (each token signed by the delegator)

BaseID implementation

Component	Crate	Tests
Trust graph	`baseid-trust`	26
Attestation builder	`baseid-trust`	(included)
Scoring algorithms	`baseid-trust`	(included)
ZK score proofs	`baseid-trust` + `baseid-bbs`	(included)
Delegation tokens	`baseid-delegation`	21
Delegation chains	`baseid-delegation`	(included)