Add Pluton attestation APIs by nguyenteresaMSFT · Pull Request #7262 · Azure/azure-sdk-for-cpp

nguyenteresaMSFT · 2026-07-28T20:06:54Z

Implementing changes for Pluton attestation support.

github-actions · 2026-07-28T20:07:22Z

Thank you for your contribution nguyenteresaMSFT! We will review the pull request and get back to you soon.

azure-pipelines · 2026-07-28T20:07:31Z

Azure Pipelines: Successfully started running 2 pipeline(s). 8 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

Copilot

Pull request overview

This PR adds initial Pluton attestation support to the Azure Security Attestation C++ client library by introducing a new AttestPluton public API and factoring shared TPM/Pluton request/response handling into a common helper.

Changes:

Added AttestationClient::AttestPluton plus corresponding AttestPlutonOptions and PlutonAttestationResult public types.
Refactored TPM attestation implementation to use a shared AttestBackend<ResultT> helper for both TPM and Pluton.
Generalized the TPM payload (de)serializer naming for reuse across TPM and Pluton.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
sdk/attestation/azure-security-attestation/src/private/attestation_deserializers_private.hpp	Renames the TPM serializer struct for shared TPM/Pluton usage.
sdk/attestation/azure-security-attestation/src/private/attestation_deserializers_private.cpp	Updates serializer implementation to match the new shared serializer name.
sdk/attestation/azure-security-attestation/src/attestation_client.cpp	Introduces `AttestBackend` helper and adds `AttestPluton` implementation.
sdk/attestation/azure-security-attestation/inc/azure/attestation/attestation_client.hpp	Exposes `AttestPluton` publicly and declares the private `AttestBackend` helper.
sdk/attestation/azure-security-attestation/inc/azure/attestation/attestation_client_options.hpp	Adds `AttestPlutonOptions`.
sdk/attestation/azure-security-attestation/inc/azure/attestation/attestation_client_models.hpp	Adds `PlutonAttestationResult`.

…for-cpp-pluton

Larry Osterman (LarryOsterman)

The API version changes are troubling and will block the ability to release anything other than a beta of this SDK client.

In general SDK clients cannot depend on preview API versions (because shipping a released SDK client forces the API version into the full release support cycle).

If your team is ok with supporting the 2026-03-11-preview release as a full GA release, then just make the API version a release version and bump the default attestation SDK version to match that version.

Larry Osterman (LarryOsterman) · 2026-08-06T17:24:12Z

+  {
+    /** @brief Attestation response data.
+     */
+    std::vector<uint8_t> PlutonResult;


Because the attestation result is unstructured data, it implies that a client cannot make any assumptions about the contents of the PlutonResult, the only thing they can depend on is the status of the operation.

That restriction may be excessively limiting to your customers, but the documentation for this API is extremely minimal.

I'm not 100% sure how any customer is going to be able to use this API.

Work to create public documentation describing the Pluton protocol messages is on our radar. Our primary goal for now is to unblock our partner team who are already acquainted with the request/response structures.

Larry Osterman (LarryOsterman) · 2026-08-06T17:26:18Z

+  };
+
+  // cspell: words plutonattestation
+  static const std::string PlutonApiVersion = "2026-03-11-preview";


Normally clients don't specify the API version and instead use the current API version. It's surprising that the pluton attestation APIs require that the customer provide a unique API version.

In general, the API version construct accepted by the Azure SDKs is flawed - the idea is that you could specify an older or newer API version on individual clients but it also meant that there could be no wire differences between the inputs and outputs of the service. But the API version defines the inputs and outputs of the service and any/all breaking changes in the wire API are required to have a version bump (thus for statically typed languages like C#, C++, Rust, Java this requires source changes on the SDK). So for statically typed languages, the use of the Api Version is strongly discouraged.

Also, this locks your clients into a preview API which also means that you force the server to support a preview version forever (at least a decade). The Attestation service currently has to support the Beta1 preview because a partner team shipped client software that depended on a preview version. You really don't want to go there.

Is there a reason you can't bump the required API version for the SDK?

My initial thought was to only expose the Pluton endpoint through a preview version because our partner team is still integrating the client component, and this SDK update is meant to unblock them. Is it preferable to have them use a preview version while they are still in development and then GA later on before shipping, or simply release 2026-03-11 as a stable API version from the start? Olga Kroshkina (@olkroshk) , Greg Kostal (@gkostal) , what do you folks think?

Here's the bottom line: Having a public release of an Azure SDK that requires a preview API version is a violation of our guidelines on API versioning. So unfortunately we can't allow a public release of an SDK client that depends on a -preview API version for any of its functionality :(.

However there's nothing stopping you from having as many beta releases as you want for your partner teams to test. But you do need to know that beta releases go into the beta package repository, so your partner teams either need to use the beta registry or they need to use a git submodule (or the moral equivalent of a git submodule) to get access to your SDK.

And honestly that's a good thing - keep the Pluton APIs with a -preview API version until you've had validation from your partner teams and then once you release the GA version, update the client TSP file with the release version and update the released version of the SDK.

And once that is done, update the SDK to require the current API version for all the APIs (I noticed there have been a few stable releases of the attestation swagger/tsp files so it's probably past time to align the TSP files and the SDKs.

** OFFTOPIC **
Oh, and while I have Greg and Olga on the line: You might want to take a stab at generating the Rust SDK for attestation - IMHO the attestation TSP file doesn't do a really good job of expressing the desired API surface of the SDK, which you can REALLY see when you look at the Rust SDK (The Rust SDKs are supposed to all be generated directly from the TSP files).

Thanks for the clarification Larry Osterman (@LarryOsterman). Our partner team is currently leveraging the SDK via git submodules, so not having an immediate public release shouldn't be a problem. With that in mind, is this PR good to merge?

I don't have a problem, but the CI pipelines are horribly red so you need to fix those before you can merge.

My initial thought was to only expose the Pluton endpoint through a preview version because our partner team is still integrating the client component, and this SDK update is meant to unblock them. Is it preferable to have them use a preview version while they are still in development and then GA later on before shipping, or simply release 2026-03-11 as a stable API version from the start? Olga Kroshkina (Olga Kroshkina (@olkroshk)) , Greg Kostal (Greg Kostal (@gkostal)) , what do you folks think?

I think Larry's guidance to go through a beta SDK release first is the route the Pluton API should take. My understanding is that this still requires the 2026-03-11-preview API version to be published before the beta SDK is officially released. Larry Osterman (@LarryOsterman), is that right?

And prior that the Pluton integration is completed with MAA, which is still in progress.
I.e., the sequences would be as follows:

For a preview/beta SDK release:

The Pluton integration is completed (still in progress).

2026-03-11-preview is published with the Pluton endpoint.

The SDK is updated to target 2026-03-11-preview.

Alternatively, for a stable/GA SDK release:

The Pluton integration is completed (still in progress).

2026-03-11-preview is published first.

A GA API version is subsequently published.

The SDK is updated to target the GA API version.

Re: "Rust SDK for attestation"

Thanks for the suggestion, Larry! I hope we have the cycles for it soon enough, and I agree it would be valuable to generate the Rust SDK and use it to evaluate the API surface produced by the current TypeSpec.

+Kelvin Sapathy (@ksapathy), David Altobelli (@daaltobe) for visibility.

Olga Kroshkina (@olkroshk) Yes, 2026-03-11-preview was published during the first Pluton-related PR that was merged. I was able to confirm the Pluton flow with the currently deployed service. The goal here now is to allow our partner team to start their integration work with this preview endpoint via this SDK.

nguyenteresaMSFT , I believe it was added internally, but I cannot find it in the official Azure API specs repo: https://github.com/Azure/azure-rest-api-specs/tree/main/specification/attestation/data-plane/Attestation .
If I am missing something, could you please share it for the review. Thank you

Larry Osterman (LarryOsterman) · 2026-08-06T17:31:11Z

+    Isolated
+  };
+
+  // cspell: words plutonattestation


Piling onto my previous comment: Non-beta Azure SDKs cannot depend on preview API versions. So until the attestation service GA's the 2026-03-11 API version, the attestation client can only be in beta release.

Larry Osterman (LarryOsterman) · 2026-08-06T17:39:47Z


 ### Features Added

+- Added `AttestationClient::AttestPluton` method for Pluton attestation support.


Add a note explaining the ApiVersion behavior for the new Pluton attestation type so developers don't get confused.

Note added.

Larry Osterman (LarryOsterman) · 2026-08-06T17:40:25Z

+     *
+     * @return Response<PlutonAttestationResult> - The result of the attestation operation
+     */
+    Response<Models::PlutonAttestationResult> AttestPluton(


Since the AttestPluton depends on a custom API version, document the requirement of the custom API version.

Note added.

Olga Kroshkina (olkroshk) · 2026-08-10T19:45:56Z

nguyenteresaMSFT , waiting for the questions to be addressed #7262 (comment)

nguyenteresaMSFT and others added 3 commits July 21, 2026 13:28

add pluton

d505f04

refactoring

42c0a24

Merge branch 'Azure:main' into main

93fdcd9

Copilot AI review requested due to automatic review settings July 28, 2026 20:06

nguyenteresaMSFT requested review from Larry Osterman (LarryOsterman), Rick Winter (RickWinter), ahmadmsft, anilba06, Greg Kostal (gkostal) and Jeff Fisher (xirzec) as code owners July 28, 2026 20:06

github-actions Bot added Attestation Community Contribution Community members are working on the issue customer-reported Issues that are reported by GitHub users external to the Azure organization. labels Jul 28, 2026

Copilot started reviewing on behalf of nguyenteresaMSFT July 28, 2026 20:07 View session

Copilot AI reviewed Jul 28, 2026

View reviewed changes

nguyenteresaMSFT added 2 commits July 29, 2026 12:01

add pluton test, parameter renaming

c09adea

Merge branch 'main' of https://github.com/nguyenteresaMSFT/azure-sdk-…

5463ecb

…for-cpp-pluton

Larry Osterman (LarryOsterman) reviewed Jul 29, 2026

View reviewed changes

Comment thread sdk/attestation/azure-security-attestation/inc/azure/attestation/attestation_client.hpp

nguyenteresaMSFT requested a review from Larry Osterman (LarryOsterman) August 6, 2026 03:46

nguyenteresaMSFT added 2 commits August 6, 2026 10:36

policy tests

68aa9f0

api version update

1760031

Larry Osterman (LarryOsterman) requested changes Aug 6, 2026

View reviewed changes

api version notes

45422cc

nguyenteresaMSFT requested a review from Larry Osterman (LarryOsterman) August 7, 2026 22:19

Larry Osterman (LarryOsterman) approved these changes Aug 10, 2026

View reviewed changes

nguyenteresaMSFT added 2 commits August 11, 2026 13:59

fix tests

cd9cbcd

update assets.json

ff79f51

Olga Kroshkina (olkroshk) self-requested a review August 12, 2026 00:41


		### Features Added

		- Added `AttestationClient::AttestPluton` method for Pluton attestation support.

Uh oh!

Conversation

nguyenteresaMSFT commented Jul 28, 2026

Uh oh!

github-actions Bot commented Jul 28, 2026

Uh oh!

azure-pipelines Bot commented Jul 28, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Larry Osterman (LarryOsterman) left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Olga Kroshkina (olkroshk) commented Aug 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants