Credential status
Two ways to learn whether a credential is revoked, and why they carry different trust.
A credential's revocation can be known in two distinct ways. They are not interchangeable: one gives you a signed fact a contract can act on, the other gives you reach across issuers Attestra has no adapter for. Pick the wrong one and you either fail to reach an issuer or hand a contract something it cannot use as evidence.
Chain-native status
The source chain holds the revocation record itself. Reading it means querying that chain, which is what an adapter does: eIDChain's adapter reads its own pallet storage, Fabric's reads its registry chaincode. The result is folded into a signed attestation, so it can be handed to a contract on any of the three chains as evidence, not merely reported to a caller.
This route only exists where Attestra has written an adapter for the source chain. It is per-chain code by construction.
W3C Bitstring Status List
The credential itself points at a published status-list credential and an
index into it, in its credentialStatus entry. Checking status means
fetching that list, decoding its bitstring, and reading one bit. No chain is
consulted at all: the list is an ordinary HTTPS resource published by the
issuer.
Because nothing chain-specific is involved, this works for any
standards-compliant issuer, with no per-chain code and no adapter. That is
reach chain-native status cannot give you: it covers issuers Attestra has
never integrated, as long as they publish a conforming status list. The
oracle's statuslist package states this directly in its design: it is
chain-independent, letting the oracle answer "is it revoked?" for a
credential from any standards-compliant issuer without a per-chain registry.
Comparison
| Chain-native status | W3C Bitstring Status List | |
|---|---|---|
| What is consulted | The source chain, via an adapter | A published status-list credential, over HTTPS |
| Signed result | Yes, a signed attestation | No, a plain read |
| Works without an adapter | No | Yes |
| What you can do with the answer | Present it to a contract as evidence | Inform a decision; nothing a contract can verify on its own |
The trade
Chain-native status gives you a signed attestation that any of the three chains can verify independently. The status list gives you reach across issuers Attestra has no adapter for, but the answer is a plain read: it is not signed, and it cannot be presented to a contract as evidence the way an attestation can. Choosing between them is choosing between provable reach and unprovable coverage; there is no option that gives you both today.
Which applies where
eIDChain has chain-native status through its adapter: a bare status lookup and presentation verification both work today.
Ethereum does not serve a bare status lookup at all; on Ethereum, revocation travels inside the credential rather than in separate oracle-queryable state. A W3C status list is the practical route for an Ethereum-issued credential today.
Hyperledger Fabric holds status in its registry chaincode, reachable through chain-native status.
Reference
- Status: the chain-native, signed lookup.
- Verify: also chain-native and signed, checking a full presentation rather than a bare hash.
- Credential status: the W3C Bitstring Status List endpoint, unsigned.