Ecosystem metrics
- New Repos
- 18
- New
- Commits
- 866
- up 0.6%
- Releases
- 7
- up 40.0%
- Contributors
- 48
- down 4.0%
- Merges
- 32
- down 11.1%
Activity Overview
Commits and releases over time
- Commits
- Releases
- Authors
Repository Explorer
No repositories match that filter.
7008 commits in all time
Jun 05, 2026 13:26 – Sep 03, 2026 13:26 UTC
fix: move OpenChainBench to alphabetical order in Metrics section
ba8018cb
pull/187/head
1/1 ++ 1 --
Merge e88d1b5578abc9037dc4a21c373df5c54fdc46fd into b0a3e71a91adfd1dfb97b5060d054618c2a147aa
83567873
pull/66/merge
10/1,219 ++ 1,300 --
chore(deps): Update all non-major dependencies
e88d1b55
renovate/all-non-major-dependencies
10/1,219 ++ 1,300 --
Merge f50cd3a2e00c87943c15b002e2cc07b16b17b639 into dab7240fc60e7e4f5061b3b36dcdf565397362e2
5e4958f1
pull/39/merge
5/306 ++ 32 --
feat: resolve our own status lists in-process, and document revocation
Phases 4 and 6 of the credential revocation plan (src/oid4vc/REVOCATION_PLAN.md), completing the stack. WHY THIS IS NOT AN OPTIMISATION CredentialAuthGuard verifies a credential on every wallet request, and every verification dereferences the status list. Without this change each wallet call makes a loopback HTTP request, and wallet authentication as a whole comes to depend on the process being able to reach itself at its own advertised hostname. In a container whose OID4VC_BASE_URL is an external name, that resolves somewhere else or nowhere, and every request 401s. Oid4vcStatusService now replaces Credo's status list fetcher at boot: URIs under our own statusListBaseUrl are answered from Vault directly, everything else is delegated to the original fetcher untouched. Since the manager is the only party checking status today, this is the enforcement path that actually runs; the HTTP endpoint exists for third-party verifiers. Two Credo internals were checked before relying on them, because either being false would have made the patch a silent no-op: - SdJwtVcService is registered with registerSingleton (SdJwtVcModule.js:24), so dependencyManager.resolve returns the instance agent.sdJwtVc.verify uses. - getBaseSdJwtConfig calls getStatusListFetcher afresh on every sign and verify, so replacing the method affects later verifications rather than being captured once at construction. getStatusListFetcher is private in the type declarations, so the patch casts. That is deliberate: Credo exposes no supported hook for supplying a fetcher, and the alternative is making wallet auth depend on server self-reachability. If a Credo upgrade breaks it, onModuleInit warns and the system falls back to HTTP rather than failing to boot. Only a single clean path segment is claimed as ours; a nested path or query string under our own base URL falls through to the network rather than being guessed at. DOCS README gains the three status endpoints, a Revocation section with curl examples, and the status list records under Storage. TRUST_MODEL no longer calls the mutable on-chain document a "revocation surface" - it is a key-rotation surface, and rotating invalidates every credential for every holder. Per-credential revocation is recorded as its own invariant, along with the gap that credentials predating the status claim can never be revoked. TESTS 216 -> 228. The new cases cover URI matching in both directions, a revocation being reflected immediately, autoInit=false leaving the fetcher untouched, and an unavailable agent warning rather than failing boot.
f50cd3a2
feat/credentials-status-local-resolve
5/306 ++ 32 --
Merge a8ebb668b48426aacc8d43ff379b5f539c373ade into fb8247d1111a5c618a32185104e0b6efd00c0f77
f8da07ba
pull/612/merge
7/172 ++ 70 --
chore: npm audit fixes
a8ebb668
fix/mutated-transactions-txids-main
3/16 ++ 62 --
Merge 67a1c98c1e67f6935eff68048e371538dd04f507 into 13dcdffc93104b06fc154de61f52e94c49484b4f
dab7240f
pull/37/merge
6/441 ++ 16 --
feat: serve and mutate credential status lists over HTTP
Phase 3 of the credential revocation plan (src/oid4vc/REVOCATION_PLAN.md). This is the half that makes the pointers embedded by PR 1 resolve: until now the app issued credentials referencing a URL nothing served. - GET credential/status/list/:listId - public, because verifiers dereference it and @sd-jwt fails verification outright if it cannot. - POST credential/status/revoke and .../reactivate - manager JWT, inherited from the global AuthGuard, addressed by issuance session id. THE LIST ROUTE WRITES ITS OWN RESPONSE It takes @Res() and calls response.end(token) rather than returning a string. @sd-jwt's default status list fetcher compares Content-Type for strict equality with application/statuslist+jwt, but Express appends "; charset=utf-8" to any string body, and Nest sends any object - a Buffer included - through response.json(). Neither ordinary return path can produce an exact media type. This matters because Credo's own fetcher does not check the media type at all. Served the obvious way, the endpoint works for every internal caller and fails only for third-party verifiers - the audience the endpoint exists for. Caught by the e2e, which deliberately uses @sd-jwt's default fetcher rather than a stub. Nothing is written before the await, so a thrown NotFoundException still renders through the exception filter. TESTS 209 -> 216 unit tests, plus a new offline e2e suite. test/status-list.e2e-spec.ts stands alone: no Vault, no chain, no separately running server. The app really listens, Vault KV is a Map with JSON round-tripped writes, and Vault transit signing is a real Ed25519 key from node's crypto - so the credential and the status list are signed by the same key, which is what Credo requires. It issues a genuine SD-JWT VC, verifies it over real HTTP, revokes it, and asserts verification then fails with "Status is not valid" while a second credential still verifies. It needs no infrastructure, so it runs locally with a path filter - `yarn test:e2e status-list` - and in CI as part of the existing yarn test:e2e step, which already has LocalNet, Vault and the compose stack up. No second jest config: e2e specs live in test/ alongside app.e2e-spec.ts.
67a1c98c
feat/credentials-status-endpoint
6/441 ++ 16 --
Merge f3cd99376f5965701239fd023a9619a7b036df3e into ec6c593a804c81f661cf4c003f17ff964d9cae95
13dcdffc
pull/36/merge
12/1,339 ++ 3 --
docs: update REVOCATION_PLAN.md
f3cd9937
feat/credentials-status-and-revoke
1/60 ++ 8 --
feat: issue SD-JWT VCs with a revocable status list entry
Phases 0-2 of src/oid4vc/REVOCATION_PLAN.md. Credentials issued by this service were bearer-forever: nothing emitted a status claim, no endpoint served one, and neither verification path checked revocation. Withdrawing one holder's access meant rotating the issuer key, which invalidates every credential ever issued for everyone. This lands the issuance half. Credentials now carry an IETF Token Status List pointer, and the machinery exists to flip a bit. The HTTP endpoint that serves the list does not exist yet (Phase 3). WHAT IS HERE - @sd-jwt/jwt-status-list promoted from a transitive dependency to a direct one, pinned exactly to the version yarn.lock already resolves, so the lockfile is untouched. - Oid4vcConfig.statusListBaseUrl / statusListUri. The URI is baked into every credential at issuance and a failed status fetch fails the entire verification, so statusListBaseUrl warns when OID4VC_BASE_URL carries no path segment - the realistic misconfiguration that would render every credential issued under it permanently unverifiable. - StatusListRecord: one Vault KV record per list, holding a fixed-size bitstring plus the next free index, pre-sized at 16384 entries (36 bytes once deflated). Size is a constant, not configuration. - Oid4vcStatusService: allocates entries at issuance, flips bits on revoke/reactivate, and serves the list as a signed statuslist+jwt. - The SD-JWT branch of the credential mapper reserves a bit and records the (list, index) pair on the local issuance session before returning anything signed. WHY IT IS SHAPED THIS WAY The status list token is signed with the manager transit key because Credo configures a single verifier for both a credential and its status list (SdJwtVcService.js:154). A list signed by any other key fails verification. This is a constraint, not a preference. The token carries no exp. @sd-jwt only checks expiry when the claim is present, and an expired list fails every credential pointing at it - an availability cliff bought for nothing, since the token is regenerated on every write. Every read-modify-write runs through one in-process queue, token building included. Building outside the queue lets a revocation land between reading the record and populating the cache, which would publish and then keep serving a token saying a revoked credential is live. The status claim is set after the claims spread so a same-named claim in issuanceMetadata cannot shadow the real revocation pointer, and it is kept out of the disclosure frame because status is reserved by SD-JWT VC and listing it in _sd makes the library throw. Allocation, persistence, then signing - in that order. A failure at either of the first two aborts issuance, because a credential whose entry was not recorded could never be revoked. The W3C JwtVc branch is deliberately untouched. Credo hardcodes 'Verifying credential status is not supported for JWT VCs', so a credentialStatus there would break verification rather than enable it. DO NOT DEPLOY THIS COMMIT ALONE Credentials issued from here point at a URL nothing serves until Phase 3. A failed status fetch throws, so any credential issued in between is permanently unverifiable. Related: credentials issued before this change carry no status claim at all, so they remain valid forever and cannot be revoked - @sd-jwt skips the check entirely when the claim is absent. Reissue at cutover if any of them matter. TESTS 24 suites / 190 tests before, 26 / 209 after. No existing test was changed. oid4vc-status.service.spec.ts signs with a real Ed25519 key from node's crypto, so the published token is verified the way a verifier would rather than merely inspected. oid4vc-issuer.service.spec.ts is new - the issuer service had no spec, so the mapper was untested in both branches. Writing those tests surfaced a pre-existing defect, recorded in the plan but deliberately not fixed here: the W3C JwtVc branch silently drops every custom claim, because Credo's W3cCredentialSubject only maps id and claims. The test pins the current behaviour rather than endorsing it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
cbd5ed04
feat/credentials-status-and-revoke
12/929 ++ 34 --
Merge cf63ac34cdd273e66dae4340eb9629e8a8563b86 into 7fdd08948797fd0e5517f8e7ed0ec0ed65d7fa22
929a22f4
pull/5/merge
5/518 ++ 27 --
fix: reject data properties colliding with setter-only capabilities; format CHANGELOG
cf63ac34
pull/5/head
3/20 ++ 5 --
feat: add implementation plan for credential status and revocation
18c3e776
feat/credentials-status-and-revoke
1/389 ++ 0 --
Merge fa3f43d1edf4b60393a259bea15695edf58ab89a into 7fdd08948797fd0e5517f8e7ed0ec0ed65d7fa22
7fbdeb27
pull/5/merge
4/499 ++ 23 --
feat: merge same-key namespace contributions, seal contributions, and lock all base properties
fa3f43d1
pull/5/head
4/406 ++ 125 --
Merge f8954364afec5f1aa76330396e676c0b7dd38a80 into 7861a68efdc034d4a01f5ba68f1acff97e28e8e6
e8b53495
pull/449/merge
1/1,272 ++ 1,232 --
chore(deps): lock file maintenance
f8954364
renovate/lock-file-maintenance
1/1,272 ++ 1,232 --
Merge b96a2a2ac36f19adbc6b8c4dcfc44fe52e6b409c into fb8247d1111a5c618a32185104e0b6efd00c0f77
624d7d0e
pull/612/merge
4/156 ++ 8 --
Add OnchainPulse ASA Safety Scanner to Metrics and Analytics Services (#186)
ea31e5b3
main
1/1 ++ 0 --
Merge branch 'main' into add-asa-safety-scanner
5dd30481
pull/186/head
15/409 ++ 216 --
Merge 1e9d4c8903eac69ca88afdcb5487097e1446e4e5 into 4958a5af0882433925c7384b7292df261c22f3fe
e0164e51
pull/187/merge
1/1 ++ 0 --