Skip to content

Comments

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

Open
michael-sabrnak-swi wants to merge 8 commits intoebourg:masterfrom
michael-sabrnak-swi:master
Open

Functional Implementation of the 2023-06-15-preview API#333
michael-sabrnak-swi wants to merge 8 commits intoebourg:masterfrom
michael-sabrnak-swi:master

Conversation

@michael-sabrnak-swi
Copy link

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.

- Added header-aware RESTResponse return path in RESTClient so callers can access operation metadata (status code, headers, parsed body, raw bytes) without reimplementing HTTP plumbing.

- Updated AzureTrustedSigningService to use the new RESTResponse, read Azure’s operation-location header, and poll the returned /sign/{operationId} URL until completion.

- Adjusted the Azure Trusted Signing tests to simulate the :sign POST plus header-driven polling flow, ensuring certificate-chain fetch, signing success/failure, and timeout cases all match the real API
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant