Functional Implementation of the 2023-06-15-preview API

[michael-sabrnak-swi]

This PR was raised in response to #332.

Here’s a quick before/after rundown between Azure Trusted Signing’s 2022-style flow and the 2023-06-15-preview version:

Endpoint shape

• 2022: Traditional REST resource paths like .../certificateprofiles/{profile}/sign (no colon).
• 2023: RPC-style .../certificateprofiles/{profile}:sign for the initial POST, while the poll endpoint moves to /sign/{operationId} and is advertised via headers. More details here.

Operation metadata

• 2022: Operation IDs typically lived in the JSON body; headers weren’t essential.
• 2023: Azure expects clients to read the operation-location header (or the embedded result.operationId) and use it to poll. Upgraded RESTClient to expose headers so the service can reliably extract that metadata.

Response contract

• 2022: Many implementations assumed the first response already contained signature data or a simple success/failure.
• 2023: The first call almost always returns InProgress, with the real signature only available after polling the operation URL until status == "Succeeded"; errors now come in the errorDetail/errors envelope.

Payload subtleties

• 2022: Mixed hashing fields (digest + optional hash lists) and some legacy algorithms.
• 2023: Focuses on base64 digests (digest, optional additional hash lists) plus stricter algorithm names (RS256, ES256, etc.) - the refactor clamps inputs to what the preview API accepts.

Client behavior

• 2022: Jsign just needed basic POST/GET calls with JSON parsing.
• 2023: Requires richer HTTP handling (headers, raw response body, poll timeouts), which is why RESTClient adjusted, updated AzureTrustedSigningService, and reworked tests to mimic that asynchronous lifecycle.

[michael-sabrnak-swi]

After further investigation, I'm closing this PR. I verified that Microsoft's own latest tooling still uses api-version=2022-06-15-preview across the board:

• Azure.CodeSigning.Sdk 0.1.164 (Nov 2025) - sole ServiceVersion enum value: V2022_06_15_preview
• Microsoft.Trusted.Signing.Client 1.0.95 (bundled in signtool dlib) - same
• Az.CodeSigning 0.2.2 PowerShell module (Mar 2025) - same
• Azure.Developer.ArtifactSigning.CryptoProvider 0.1.72 (Mar 2026) - depends on the same SDK

Every downstream tool - the GitHub Action (azure/artifact-signing-action), Azure DevOps tasks (ArtifactSigning 1.0.0, TrustedSigning 0.5.13), the TrustedSigning PowerShell module 0.5.8, and the Notation plugin - all transitively use this same chain. The DLL string tables show REST-style /sign paths (not :sign RPC), and the only API version literal embedded is 2022-06-15-preview.

No newer data plane API version has been published in any Microsoft SDK, and the data plane OpenAPI spec is still not in azure-rest-api-specs (the link referenced in this PR returns 404).

The original issue (#332) was actually caused by a trailing slash in the endpoint URL producing //codesigningaccounts/... double-slashes, which started returning 404 after Microsoft tightened URL normalization - not by an API version problem.

[ebourg]

Thank you for the info, I'll probably apply the PR when the new API is more widely used.