Publish the original Jwt module as-is under PSModule maintenance

[MariusStorhaug]

Jwt is already published on PowerShell Gallery, and existing automation can install and use it today without any redesign. The immediate maintenance need is to keep that original module available from the current PSModule/Jwt repository and publish a continuation release without bundling broader refactors or new JWT feature work.

Request

User impact

Users who already depend on Jwt need a stable maintenance path so the package continues to be installable, attributable to an active repository, and publishable by the current maintainers. Without that continuity, consumers are left with an effectively orphaned package even though the existing command surface is still useful.

Current experience

The repository contains the current module source, but there is no issue scoped only to publishing the original module under current maintenance. Related issues such as #16 and #13 expand the scope into source alignment or new capabilities, which makes it unclear whether the first step is a conservative publication of the original module or a larger redevelopment effort.

Desired experience

Jwt should be published from PSModule/Jwt as the next maintained release while preserving the original public commands and observable behavior from Jwt 1.9.1. Follow-up cleanup, alignment to PSModule conventions, and feature expansion should remain in separate issues so this work stays focused on continuity of maintenance and publication.

Acceptance criteria

• A maintained release of Jwt is published from PSModule/Jwt to PowerShell Gallery under the existing Jwt package identity.
• The published package preserves the public commands, aliases, and observable behavior of Jwt 1.9.1 unless a separate issue explicitly defines a behavioral change.
• Module metadata and gallery-facing links point to the current repository and maintenance ownership where supported by PowerShell Gallery.
• The published package installs in a clean PowerShell 7 session with Install-PSResource -Name Jwt, imports successfully, and supports representative existing commands such as New-Jwt, Get-JwtHeader, Get-JwtPayload, and Test-Jwt.
• Source-alignment work stays tracked in Align the published Jwt module source with PSModule design principles #16 and broader Jwt feature work stays tracked in Implement JWT creation, parsing, validation, inspection, and JWK functions #13 instead of being folded into this publication issue.

---

Technical decisions

Publication target: Publish to the existing PowerShell Gallery Jwt package. This is a continuation of maintenance, not a rename, replacement package, or forked distribution.

Versioning: Use the next patch version after 1.9.1, because the goal is continuity of ownership and publication without intentional feature or behavior changes.

Scope boundary: Keep the module behavior effectively as-is. Only make the minimal metadata, packaging, repository, or publish-pipeline changes required to ship the maintained release.

Ownership prerequisite: Confirm that the current maintainers have publish access to the existing PowerShell Gallery package before release. If ownership transfer or owner addition is required, that work is part of this issue and blocks publication.

Related work: This issue is intentionally narrower than #16 and #13. #16 aligns the repository to PSModule design conventions, and #13 expands Jwt capabilities. Neither should block the initial maintenance publication unless a specific packaging defect prevents the release.

Validation strategy: Validate the release by installing the newly published package into a clean PowerShell 7 session and exercising representative commands from the current README usage.

---

Implementation plan

Ownership and metadata

• Confirm or update the owners for the existing Jwt package on PowerShell Gallery so the current maintainers can publish it.
• Update module metadata and package links only where needed to reflect the current repository and maintenance ownership without changing the public command surface.

Packaging and publication

• Verify the repository can build the current module package without bundling unrelated refactors or new feature work.
• Set the module version to the next patch release for the maintained continuation of Jwt 1.9.1.
• Publish the package from PSModule/Jwt to PowerShell Gallery under the existing Jwt name.

Validation

• Install the newly published package in a clean PowerShell 7 environment with Install-PSResource -Name Jwt and confirm Import-Module Jwt succeeds.
• Run representative commands against the published package to confirm the original module behavior remains available.

Follow-up coordination

• Keep repository-alignment work in Align the published Jwt module source with PSModule design principles #16 and broader JWT capability work in Implement JWT creation, parsing, validation, inspection, and JWK functions #13 as follow-up issues rather than expanding this issue during publication.

[MariusStorhaug]

During PR #18 review, Copilot identified concrete Jwt parsing and crypto hardening bugs that go beyond this publication-continuity issue's original scope. I created #19 to track that additional fix scope explicitly, and PR #18 now references both issues.

The publication tasks in this issue still remain the release-process source of truth for Gallery ownership, actual publication, and clean post-publish validation after merge.