Skip to content

v3.3.0

Latest

Choose a tag to compare

@luisgf luisgf released this 04 Jul 08:21

Feature release: issuance of W3C Data Integrity (Linked Data Proof) credentials — the signing counterpart to the verification shipped in v3.2.0. Open Badges 3.0 now issues and verifies in both proof formats the spec allows — compact VC-JWT (JOSE) and embedded Data Integrity — from one offline library. Data Integrity stays opt-in via the [ldp] extra, which now covers both directions:

pip install "openbadgeslib[ldp]"

Added

  • feat(ob3): OB3LdpSigner issues OB 3.0 credentials carrying an embedded Data Integrity proof, cryptosuite eddsa-rdfc-2022 — the signing counterpart of the 3.2.0 verifier, sharing its canonicalization core and reproducing the official W3C vc-di-eddsa test vector byte for byte. The low-level core is exposed as add_data_integrity_proof for non-OB3 VCs. Ed25519 keys only; requires the [ldp] extra, which now covers signing and verification.
  • feat(cli): openbadges-signer -P/--proof-format {vc-jwt,ldp} (OB 3.0 only), plus an optional per-badge proof_format config key (the flag wins; default stays vc-jwt). With [issuer] did configured, the proof names the did:web:…#badge_N verificationMethod that openbadges-publish -V 3 publishes (trusted on verify via --resolve-did); otherwise it falls back to a self-asserted did:key derived from the signing key and tells the operator so. LDP-signed badges are tagged PROOF ldp in the signer audit log. Status lists stay VC-JWT regardless of the badge's proof format.
  • feat(ob3): multikey / did:key encoders in ob3.didmultikey_from_pem (publicKeyMultibase) and did_key_from_pem, the exact inverses of the resolvers, for Ed25519 and NIST P-256.

Fixed

  • fix(cli): Badge.create_from_conf rejected key_type = ED25519 outright, so the CLI could never sign with the keys openbadges-keygenerator -t ED25519 produces. Ed25519 key material now loads, and the legacy OB 1.0 path (-V 1) refuses non-RSA/ECC keys with a clean message instead of failing mid-JWS.

Not included (deferred): the ecdsa-sd-2023 selective-disclosure cryptosuite — no Python library in the ecosystem implements it yet; it fails closed with a clear "unsupported cryptosuite" message, and the cryptosuite registry keeps it an additive future module.

Everything still works without the extra: the base install is unchanged, LDP tests skip cleanly, and attempting LDP signing/verification reports pip install openbadgeslib[ldp].

Verified with flake8, mypy (strict) and the full test suite (805 passed with the [ldp] extra) locally, and the CI matrix on Python 3.10–3.13, which gated the automatic PyPI publish.

Full history: Changelog.txt