openbadgeslib 4.6.0__tar.gz → 4.6.2__tar.gz

{openbadgeslib-4.6.0 → openbadgeslib-4.6.2}/CONTRIBUTING.md

@@ -85,7 +85,7 @@ policy is deliberately simple and predictable:
 - A new CPython minor is **added** to the CI matrix and the classifiers once it
   has a stable (non-pre) release, so downstreams can adopt it early.
 - The current matrix is **3.10–3.15**, and `requires-python = ">=3.10"`.
-  Python **3.10 is deprecated** since 4.6.0 (EOL 2026-10-31) and is dropped in
+  Python **3.10 is deprecated** since 4.6.0 (EOL 2026-10-01) and is dropped in
   5.0, which will require Python 3.11+
   ([#242](https://github.com/luisgf/openbadgeslib/issues/242)).
 

{openbadgeslib-4.6.0 → openbadgeslib-4.6.2}/Changelog.txt

@@ -4,6 +4,270 @@ OpenBadgesLib - Changelog
 Newest first. Dates are ISO 8601 (YYYY-MM-DD).
 
 
+* v4.6.2 - 2026-10-16
+
+  - security(deps): the openvc-core floor of `[eudi]`, `[ldp-sd]` and
+    `[oid4vci]` rises to 1.35.0. Two behaviours below it reach this
+    library's public API. An SD-JWT VC whose issuer JWT carries `aud`
+    verified for any relying party, so a badge its issuer restricted to one
+    verifier was honoured by all (RFC 7519 §4.1.3); 1.35.0 enforces it, and
+    `verify_badge_sd_jwt(audience=…)` now also gates it. And
+    `status_list_token_resolver(leeway_s=…)` took any number, so an infinite
+    leeway made an expired status-list token verify as current; 1.35.0
+    accepts whole seconds from 0 to 86400 only. Neither is an advisory in
+    openvc-core. The run-time guard of the ecdsa-sd-2023 verify path stays at
+    1.33.2, the security minimum of that path. `[ldp]` and `[ldp-sd]` also cap
+    pyld below 4: pyld 4.0 (unreleased, breaking) drops statements from the
+    signed dataset that 3.x keeps, an IRI with two `#` or a literal with an
+    invalid `@language`, which context validation does not refuse, so the
+    credential would still show what the proof no longer covers.
+
+  - security(eudi): `verify_badge_sd_jwt` enforces the badge's own
+    `validFrom` and `validUntil` on both trust paths (pinned key and X.509
+    trust anchors), and `issue_badge_sd_jwt` writes the credential's
+    `validUntil` as the issuer JWT's `exp`, and a `validFrom` still ahead as
+    `nbf`. A badge is a flat IETF SD-JWT VC, and openvc-core reads
+    `validFrom` / `validUntil` as a validity window only for a W3C VCDM
+    payload, so a badge past its `validUntil` verified as unexpired unless
+    `expires_in_s` happened to be passed; badges issued by other
+    implementations with only a `validUntil` were affected the same way. The
+    earlier of `validUntil` and `expires_in_s` wins, a window value that is
+    not an ISO 8601 timestamp with an offset (as `datetime.fromisoformat`
+    reads it, which is stricter before Python 3.11) fails closed, and the
+    leeway is the 60 seconds the other OB 3.0 verifiers use.
+    `issue_badge_sd_jwt` now refuses, with `EudiError`, to make `name`,
+    `achievement`, `validFrom` or `validUntil` selectively disclosable: a
+    holder could withhold the disclosure and present an expired badge as one
+    that never expires, and the stripped presentation still verified. Only
+    the recipient (`credentialSubject`) is meant to be withheld. A bare string
+    for `disclosable=` is refused too (it was read one character at a time,
+    which left the recipient in the clear), and `expires_in_s` must be a
+    number within about 317 years of now. Nothing can detect a withheld
+    disclosure on a badge that already exists, and an existing badge has no
+    `exp`/`nbf` for other verifiers: re-issue badges issued with a
+    `disclosable=` that named one of those claims, and any badge that must
+    stop verifying at its `validUntil` everywhere. The Type Metadata document
+    is unchanged, byte for byte (a change would break the `vct#integrity` pin
+    of every badge already issued), and a test now pins its hash.
+    With `x5c_trust_anchors`, `verify_badge_sd_jwt` no longer accepts a plain
+    JWT (a token with no `~`): openvc-core's `verify_credential` takes one
+    and then ignored `expected_vct` and `require_key_binding` and returned
+    another type, so a JWT signed by an anchored issuer passed as a badge;
+    the pinned-key path always refused it. `status_list_token_resolver`
+    validates `leeway_s` when it is built, so a bad value fails there rather
+    than on the first status check of a later badge. A hostile issuer JWT
+    header nested deeper than the JSON parser recurses now fails as
+    `EudiError` instead of escaping `verify_badge_sd_jwt(x5c_trust_anchors=…)`
+    as a bare `RecursionError`, and a window value too long to be a timestamp
+    is not echoed back in the error.
+
+  - fix(did): a `did:web` document nested deeper than the JSON parser
+    recurses, or deeper than 64 levels (a DID document is a handful), is
+    reported as the usual `OB3VerificationError` instead of escaping
+    `resolve_did`, `fetch_did_web_document` and the verifiers that resolve an
+    issuer's DID as a bare `RecursionError`. CPython 3.14 and later parse
+    nesting far past the recursion limit, so the parser alone no longer bounds
+    what the later `repr()` and `json.dumps` of the document survive.
+
+* v4.6.1 - 2026-10-14
+
+  - security(ldp): `OB3LdpVerifier` reads only JSON its Data Integrity proof
+    actually covers (GHSA-rp5q-966c-5592; affects 3.2.0–4.6.0, the native
+    eddsa-rdfc-2022 path). The proof signs the RDF dataset the credential
+    expands to, while the returned credential and every policy check
+    (validity window, `credentialStatus`, recipient, issuer binding,
+    `proof.expires`) read the JSON, and nothing tied the two together. Many
+    JSON documents expand to the same dataset, so an expired or revoked
+    badge, or one showing forged content, verified with its genuine
+    signature, including on the DID-resolved, issuer-bound path. `verify`
+    now applies VC Data Integrity §2.4.1 context validation before it builds
+    the credential or applies any policy, for both cryptosuites and ahead of
+    the ecdsa-sd-2023 delegation: `@context` starts with the VC 2.0 URL and
+    names only bundled contexts, each context document once and at most
+    eight entries in all, so a padded `@context` cannot buy seconds of
+    JSON-LD processing before any key is resolved, and no inline context
+    object, not even a bare `@vocab` (OB 3.0 credentials name only
+    published contexts; a holder-chosen vocabulary would only add spellings
+    of signed members to refuse). Those bounds hold for every `@context` the
+    JSON-LD processor applies and are checked before it runs: below the top
+    level only an embedded endorsement credential may carry one, held to
+    the same rules, and any other is refused, even inside an `@json`
+    literal such as `_sd`; and since each embedded credential is validated
+    again on its own, at most 64 may be embedded, 8 deep, with at most
+    256 KiB of their JSON in all (a nested one counted once per credential
+    holding it). The document and its proof configuration must each be the
+    compacted form of their own expansion, with every member (and `type`
+    value) a bundled context defines spelled by its term; and nothing may
+    be dropped on the way to RDF ("safe mode"). That
+    refuses a member re-keyed to its IRI or aliased by an inline context, a
+    value its term cannot carry (an untyped `validUntil`/`validFrom` or
+    proof `expires`, or a literal `credentialStatus`: compaction itself
+    keeps such a value under the full IRI, out of sight of the policy,
+    which reads the term), `@included`, `@reverse`, `@index`, `@direction`, a
+    top-level `@graph`, a second description of the credential's own node,
+    an array nested inside an array (expansion flattens `[[S]]` into the
+    same signed dataset as `S`, while the status checker reads only objects,
+    so a wrapped `credentialStatus` skipped the revocation check), and any
+    term, type or node id that is undefined or not an absolute IRI. Every
+    `credentialStatus` entry must also be a JSON object: a bare status
+    reference, which no checker can read, is refused rather than treated as
+    no status. Embedded endorsement credentials are validated against their
+    own `@context`. `OB3LdpSigner.sign` checks what it produced and raises
+    `ErrorSigningFile` rather than emit a document its proof does not fully
+    cover (e.g. a recipient id without a scheme), or one whose
+    `sign_to_json` text exceeds the 256 KiB verifiers accept. Now refused
+    because part of them was never signed: credentials with an undefined
+    term or type, or a relative or malformed id (pyld >= 3.1 signed an
+    undefined type or a relative id as `http://example.org/base/...`),
+    including the shape openbadgeslib 3.6.0 to 3.14.0 issued, a
+    `credentialSchema` typed `1EdTechJsonSchemaValidator2019` without the
+    extensions context (#239): re-issue such badges. The size limit is still
+    applied once, to the document as received. The low-level
+    `verify_data_integrity_proof` / `add_data_integrity_proof` are unchanged
+    for eddsa-rdfc-2022 (CLR and the W3C vectors use them): they verify or
+    sign the RDF dataset only, so do not read validity, status, subject or
+    issuer from the JSON after `verify_data_integrity_proof` alone; verify
+    OB 3.0 credentials with `OB3LdpVerifier`.
+
+  - security(ldp): `OB3LdpVerifier` refuses a member the policy reads
+    spelled by its full IRI even where no bundled context defines a term
+    for it. OB 3.0 was first published on VCDM 1.1, so issuers signed
+    eddsa-rdfc-2022 badges carrying `issuanceDate`/`expirationDate` (and
+    perhaps a `StatusList2021Entry`); those are refused as issued, since the
+    VC 1.1 context is not bundled, but a holder could re-compact one onto
+    `[VC 2.0, OB 3.0]` with the dataset and the signature unchanged:
+    compaction then spelled those members by full IRI, and the model saw no
+    expiry, no not-before and a status entry type it did not know. Every IRI
+    the policy reads (the validity window of both VC data models,
+    `proof.expires`, `credentialStatus`, `credentialSchema`,
+    `credentialSubject`, `issuer`, and the Bitstring and StatusList2021
+    entry types and members) must now be spelled by the one key the policy
+    reads it under, from a fixed table rather than from the bundled
+    contexts, so an alias a future context gave one is refused too. VC 1.1
+    is still not bundled: such badges stay unverifiable; re-issue them on
+    VC 2.0.
+
+  - security(ldp): `OB3LdpVerifier` refuses a `credentialStatus` entry that
+    is also described outside `credentialStatus`. RDF lets a node referenced
+    from two properties be described under either, so when the issuer also
+    named its status entry from another property (`relatedResource`, a
+    nested node's or an embedded endorsement's own `credentialStatus`), a
+    holder could move a signed member such as `statusSize: 2` there with the
+    dataset and the signature unchanged, and the status check read the wrong
+    bit and reported a revoked badge as valid. A node directly under the
+    top-level `credentialStatus` whose id is described anywhere else in the
+    expanded document is now refused, unless that description is an exact
+    copy of the entry (as when an embedded endorsement repeats the outer
+    credential's `credentialStatus` verbatim). An issuer-signed credential
+    that describes its status entry under a second property with more than
+    its id is refused too: re-issue it naming the entry by id only.
+
+  - security(ldp): an ecdsa-sd-2023 presentation passes `OB3LdpVerifier`
+    only if every `validUntil` and `credentialStatus` statement it discloses
+    is mandatory. The #328 check saw only that the two keys were there, so
+    with status left selective a holder could disclose one status entry of
+    two (the clear one), or an entry without its `statusSize`, and pass the
+    status check. A verifier cannot count what a holder withheld, only rely
+    on the mandatory statements the issuer's base signature covers as a
+    whole, so issuers must list `/validUntil` and `/credentialStatus` as
+    mandatory pointers; presentations of credentials that left them
+    selective are now refused even when fully disclosed. The limit no
+    verifier can lift: what an issuer leaves selective stays hideable, so a
+    mandatory `/credentialStatus/0` alone leaves `/credentialStatus/1`
+    hideable; mark `/credentialStatus` whole. The check indexes the
+    disclosed statements with openvc-core's own ecdsa-sd-2023 helpers and
+    fails closed if they are missing. `verify_data_integrity_proof` still
+    checks the proof alone.
+    - `validFrom` is held to the same rule as `validUntil` and
+      `credentialStatus`: a presentation that omits it, or whose issuer
+      left `/validFrom` selective, is refused. Otherwise the holder of a
+      badge that is not valid yet could withhold its `validFrom`, which the
+      model then took as "now", and present it as valid. Issuers list
+      `/validFrom`, `/validUntil` and `/credentialStatus` as mandatory
+      pointers.
+
+  - fix(ob3): a `credentialStatus` entry whose `statusPurpose` or `type`,
+    or a credential whose `type`, is not a string (a holder can respell a
+    signed `"revocation"` as `["revocation"]` in a Data Integrity credential
+    without changing what is signed; an issuer can sign a language-tagged
+    value) fails with `OB3VerificationError` instead of a bare `TypeError`,
+    and before the status list is fetched.
+
+  - security(deps): raise the `[ldp]` pyld floor to `>=3.3.0`, the release
+    the suite is tested against, and declare the same floor in `[ldp-sd]`
+    (openvc-core's own `[data-integrity]` extra admits pyld 2.x, and
+    `OB3LdpVerifier` validates with pyld before it delegates). Context
+    validation compares the JSON with the compacted form pyld derives, and
+    pyld 2.x compacts some terms differently (an `Address.geo` comes back as
+    `GeoCoordinates`), so genuine credentials such as 1EdTech's "Complete
+    OpenBadgeCredential" example would be refused. pyld before 3.3 also
+    canonicalizes an integral float (`3.0`) as `"3.0E0"`, where 3.3 and
+    jsonld.js give `"3"`, so a Data Integrity proof made on one did not
+    verify on the other.
+
+  - security(deps): raise the openvc-core floors to `>=1.33.2` in the
+    `[eudi]`, `[ldp-sd]` and `[oid4vci]` extras, the release the suite is
+    tested against. openvc-core 1.30.2 closes the same JSON-vs-dataset gap
+    in the ecdsa-sd-2023 suite `[ldp-sd]` delegates to
+    (GHSA-vrxg-57v4-85mc), and 1.33.2 its follow-ups (GHSA-h9rq-wxcw-4rjc:
+    nested arrays, re-spelled policy terms, a derived proof that merges
+    blank nodes). The ecdsa-sd-2023 verify (`OB3LdpVerifier`
+    and `verify_data_integrity_proof` alike) now also refuses, at run time,
+    an installed openvc-core older than 1.33.2 or with no readable version
+    (`OB3VerificationError`), so a stale environment fails closed. Behaviour
+    the new floor brings: `verify_badge_sd_jwt` on a presentation carrying a
+    Key Binding JWT, called with only `audience` or only `nonce` (or one of
+    them empty), raises `EudiError` instead of reporting `key_bound=True`
+    for a KB-JWT never bound to this verifier (openvc-core 1.30.0); and an
+    ecdsa-sd-2023 document with an undefined term or an inline `@context`
+    that defines terms is rejected. CI's `eudi` job now runs the `[eudi]`
+    and `[ldp-sd]` suites at that exact floor and fails if the extras'
+    floors disagree.
+
+  - security(deps): raise the PyJWT[crypto] floor to `>=2.15.1`. The OB3
+    JWT-VC verifier hands an untrusted token to
+    `jwt.get_unverified_header()`, to an unverified `jwt.decode()` peek that
+    reads the issuer before its key is resolved, and to the
+    signature-verifying `jwt.decode()`, so these PyJWT advisories are on a
+    reachable path: a deeply nested header (2.14.0, GHSA-8wjv-2p76-3863,
+    which affects the old 2.13 floor) or payload (2.15.0,
+    GHSA-42vr-xj54-vc7v, through the unverified peek) escaped as a bare
+    `RecursionError` instead of an `OB3VerificationError`; and characters
+    outside the base64url alphabet were accepted in a segment, so one
+    signature verified under many spellings of a token (2.14.0,
+    GHSA-hxm8-2xgr-2p9m; its revocation bypass needs a consumer that indexes
+    revocation by token text, which openbadgeslib does not do). 2.15.1
+    rather than 2.15.0 because 2.14.0 and 2.15.0 also refused canonical `=`
+    padding (PyJWT #1209). The HMAC key-confusion, options-dict and
+    `PyJWKClient` advisories are not reachable: no HS* algorithm is ever
+    allowed, every call passes a fresh options dict, and `PyJWKClient` is
+    not used. `environment.yml`, the README and the Installation page
+    follow, and a docs test now pins their PyJWT floor to `pyproject.toml`.
+
+  - fix: the Python 3.10 deprecation gives the real CPython end-of-life
+    date, 2026-10-01 (PEP 619); v4.6.0 said 2026-10-31. The
+    `DeprecationWarning` now reads "(CPython end of life: 2026-10-01)", and
+    the README, Installation, Upgrading and contributing docs follow. Its
+    prefix is unchanged, so the documented
+    `ignore:Python 3.10 is deprecated in openbadgeslib:DeprecationWarning`
+    filter still matches, and 3.10 stays supported through 4.x.
+
+  - fix(ob3): integral `creditsAvailable` / `creditsEarned` values are
+    emitted as JSON integers (`3`, not `3.0`). Both are `xsd:float` terms,
+    and JSON-LD gives an integral number the integer lexical form (`"3"`),
+    which jsonld.js and pyld 3.3 sign; pyld before 3.3 signed the float
+    `3.0` as `"3.0E0"`, so a Data Integrity badge issued with integral float
+    credits verified only on the pyld version it was signed with. New badges
+    now canonicalize the same everywhere. Data Integrity badges already
+    issued with integral float credits on pyld <= 3.1 do not verify on pyld
+    3.3 or jsonld.js-based verifiers; re-issue them. The model still reads
+    the values back as floats.
+
+  - fix(ldp): a deeply nested Data Integrity document fails with
+    `OB3VerificationError` instead of escaping `OB3LdpVerifier.verify` (and
+    the issuer-DID peek in `verify_badge`) as a bare `RecursionError`.
+
+
 * v4.6.0 - 2026-10-13
 
   - feat: Python 3.15 is officially supported (#243). It joins the

{openbadgeslib-4.6.0 → openbadgeslib-4.6.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: openbadgeslib
-Version: 4.6.0
+Version: 4.6.2
 Summary: Production-ready Python library & CLI for Open Badges 3.0 (W3C Verifiable Credentials): issue, verify, and revoke JWT-VC credentials with Bitstring Status Lists and did:web — plus strict OB 2.0 and legacy OB 1.0.
 Author-email: Luis González Fernández <luisgf@luisgf.es>, Jesús Cea Avión <jcea@jcea.es>
 License: LGPLv3
@@ -31,17 +31,18 @@ Requires-Python: >=3.10
 Description-Content-Type: text/markdown
 License-File: LICENSE.txt
 Requires-Dist: pypng>=0.20220715.0
-Requires-Dist: PyJWT[crypto]>=2.13
+Requires-Dist: PyJWT[crypto]>=2.15.1
 Requires-Dist: cryptography>=45
 Requires-Dist: defusedxml>=0.7
 Provides-Extra: ldp
-Requires-Dist: pyld>=2.0.4; extra == "ldp"
+Requires-Dist: pyld<4,>=3.3.0; extra == "ldp"
 Provides-Extra: eudi
-Requires-Dist: openvc-core<2,>=1.26; extra == "eudi"
+Requires-Dist: openvc-core<2,>=1.35.0; extra == "eudi"
 Provides-Extra: ldp-sd
-Requires-Dist: openvc-core[data-integrity]<2,>=1.26; extra == "ldp-sd"
+Requires-Dist: openvc-core[data-integrity]<2,>=1.35.0; extra == "ldp-sd"
+Requires-Dist: pyld<4,>=3.3.0; extra == "ldp-sd"
 Provides-Extra: oid4vci
-Requires-Dist: openvc-core<2,>=1.26; extra == "oid4vci"
+Requires-Dist: openvc-core<2,>=1.35.0; extra == "oid4vci"
 Provides-Extra: dev
 Requires-Dist: pytest>=8.0; extra == "dev"
 Requires-Dist: pytest-cov>=5.0; extra == "dev"
@@ -69,7 +70,7 @@ with W3C Bitstring Status Lists and `did:web`. It also ships strict
 **OpenBadges 2.0** (JWS / hosted assertions) and a frozen **OpenBadges 1.0**
 legacy format, selected with `-V {1,2,3}` (default `3`).
 
-> **4.0.0 is released** (2026-07-22). It groups the breaking changes so upgrades stay rare: every CLI unifies on one `0/1/2` exit-code contract (a valid-but-untrusted badge now exits `2`, and the 255s are gone), and the legacy pycryptodome/python-ecdsa compat shim is removed — a live key **object** from either is no longer accepted, though key *files* are plain PEM and round-trip unchanged. OpenBadges 1.0 and the `openbadges-<command>` scripts stay, and a new unified `openbadges <command>` front-end joins them. **Python 3.10 stays supported throughout 4.x** (`requires-python >= 3.10`; CI tests 3.10–3.15) but is deprecated since 4.6.0, ahead of its 2026-10-31 end of life; 5.0 drops it and requires Python 3.11+. See **[Upgrading to 4.0](https://github.com/luisgf/openbadgeslib/wiki/Upgrading-to-4.0)** before pinning a major.
+> **4.0.0 is released** (2026-07-22). It groups the breaking changes so upgrades stay rare: every CLI unifies on one `0/1/2` exit-code contract (a valid-but-untrusted badge now exits `2`, and the 255s are gone), and the legacy pycryptodome/python-ecdsa compat shim is removed — a live key **object** from either is no longer accepted, though key *files* are plain PEM and round-trip unchanged. OpenBadges 1.0 and the `openbadges-<command>` scripts stay, and a new unified `openbadges <command>` front-end joins them. **Python 3.10 stays supported throughout 4.x** (`requires-python >= 3.10`; CI tests 3.10–3.15) but is deprecated since 4.6.0 (it reached end of life on 2026-10-01); 5.0 drops it and requires Python 3.11+. See **[Upgrading to 4.0](https://github.com/luisgf/openbadgeslib/wiki/Upgrading-to-4.0)** before pinning a major.
 
 ## Features
 
@@ -147,7 +148,7 @@ all three OB versions.
   openbadgeslib 5.0 will require Python 3.11 or newer
   ([#242](https://github.com/luisgf/openbadgeslib/issues/242)).
 - [pypng](https://pypi.org/project/pypng/) >= 0.20220715.0
-- [PyJWT[crypto]](https://pypi.org/project/PyJWT/) >= 2.13
+- [PyJWT[crypto]](https://pypi.org/project/PyJWT/) >= 2.15.1
 - [cryptography](https://pypi.org/project/cryptography/) >= 45
 - [defusedxml](https://pypi.org/project/defusedxml/) >= 0.7
 

{openbadgeslib-4.6.0 → openbadgeslib-4.6.2}/README.md

@@ -13,7 +13,7 @@ with W3C Bitstring Status Lists and `did:web`. It also ships strict
 **OpenBadges 2.0** (JWS / hosted assertions) and a frozen **OpenBadges 1.0**
 legacy format, selected with `-V {1,2,3}` (default `3`).
 
-> **4.0.0 is released** (2026-07-22). It groups the breaking changes so upgrades stay rare: every CLI unifies on one `0/1/2` exit-code contract (a valid-but-untrusted badge now exits `2`, and the 255s are gone), and the legacy pycryptodome/python-ecdsa compat shim is removed — a live key **object** from either is no longer accepted, though key *files* are plain PEM and round-trip unchanged. OpenBadges 1.0 and the `openbadges-<command>` scripts stay, and a new unified `openbadges <command>` front-end joins them. **Python 3.10 stays supported throughout 4.x** (`requires-python >= 3.10`; CI tests 3.10–3.15) but is deprecated since 4.6.0, ahead of its 2026-10-31 end of life; 5.0 drops it and requires Python 3.11+. See **[Upgrading to 4.0](https://github.com/luisgf/openbadgeslib/wiki/Upgrading-to-4.0)** before pinning a major.
+> **4.0.0 is released** (2026-07-22). It groups the breaking changes so upgrades stay rare: every CLI unifies on one `0/1/2` exit-code contract (a valid-but-untrusted badge now exits `2`, and the 255s are gone), and the legacy pycryptodome/python-ecdsa compat shim is removed — a live key **object** from either is no longer accepted, though key *files* are plain PEM and round-trip unchanged. OpenBadges 1.0 and the `openbadges-<command>` scripts stay, and a new unified `openbadges <command>` front-end joins them. **Python 3.10 stays supported throughout 4.x** (`requires-python >= 3.10`; CI tests 3.10–3.15) but is deprecated since 4.6.0 (it reached end of life on 2026-10-01); 5.0 drops it and requires Python 3.11+. See **[Upgrading to 4.0](https://github.com/luisgf/openbadgeslib/wiki/Upgrading-to-4.0)** before pinning a major.
 
 ## Features
 
@@ -91,7 +91,7 @@ all three OB versions.
   openbadgeslib 5.0 will require Python 3.11 or newer
   ([#242](https://github.com/luisgf/openbadgeslib/issues/242)).
 - [pypng](https://pypi.org/project/pypng/) >= 0.20220715.0
-- [PyJWT[crypto]](https://pypi.org/project/PyJWT/) >= 2.13
+- [PyJWT[crypto]](https://pypi.org/project/PyJWT/) >= 2.15.1
 - [cryptography](https://pypi.org/project/cryptography/) >= 45
 - [defusedxml](https://pypi.org/project/defusedxml/) >= 0.7
 

{openbadgeslib-4.6.0 → openbadgeslib-4.6.2}/openbadgeslib/_python_support.py

@@ -20,12 +20,13 @@
 """
 
 # The runtime side of the "Supported Python versions" policy (CONTRIBUTING.md):
-# a CPython that is still supported but nearing (or past) end of life is
-# deprecated — importing openbadgeslib on it emits a DeprecationWarning — and
-# is dropped only at the next major release.
+# a CPython that is still supported but past (or in its final months before)
+# end of life is deprecated — importing openbadgeslib on it emits a
+# DeprecationWarning — and is dropped only at the next major release.
 #
-# Python 3.10 is deprecated since 4.6.0 and dropped in 5.0 (#242). That drop
-# raises requires-python, the mypy python_version and DEPRECATED_BELOW together,
+# Python 3.10 reached CPython end of life on 2026-10-01 (PEP 619); it is
+# deprecated since 4.6.0 and dropped in 5.0 (#242). That drop raises
+# requires-python, the mypy python_version and DEPRECATED_BELOW together,
 # rewording DEPRECATION_MESSAGE for the next deprecated version — or deletes
 # this module (and its call in __init__) if none is pending removal.
 
@@ -38,7 +39,7 @@ DEPRECATED_BELOW = (3, 11)
 
 DEPRECATION_MESSAGE = (
     'Python 3.10 is deprecated in openbadgeslib (CPython end of life: '
-    '2026-10-31); openbadgeslib 5.0 will require Python 3.11 or newer.')
+    '2026-10-01); openbadgeslib 5.0 will require Python 3.11 or newer.')
 
 
 def warn_if_deprecated(version_info: Tuple[object, ...] = sys.version_info) -> None: