Support AWS V2 Java API

[notnarb]

TL;DR: AWS maintains 2 versions of their Java AWS libraries, I'm willing to submit a new client for the 2nd version.

Help us help you

Our team is using Tink for hybrid encryption and one of our planned deployment targets are AWS Lambda functions in Java.

Is your feature request related to a problem?

Currently the AWS KMS implementation provided with Tink for Java uses the V1 API com.amazonaws.services.*

Note: as far as I am aware, the "V2" Java API is a difference in client implementation and not a separate HTTP endpoint with different behavior

The big advantages I see for Tink offering an integration with the V2 API client (software.amazon.awssdk.*) are:

• Allowing replacement of the HTTP client implementation ("pluggable http layer")
  • HTTP client can also be reused between V2 clients
• Decreased jar size for apps already using V2 of the API
• Credential provider can be reused with V2 clients

These features are important for startup-latency-sensitive environments like ours (Lambda functions), but I'll admin these are probably not very important for the majority of AWS x Tink x Java users.

Describe the solution you'd like

• A new AwsKmsV2Client (and corresponding AwsKmsV2Aead) class specifically for supporting the V2 Java AWS client.
• A new method withHttpClient() unique to this client.

cons: increased surface area, more code to maintain

Describe alternatives you've considered

1. Replacing the V1 client with the V2 client.

Less code to maintain and presumably the V2 client is better but this would be a breaking change because withCredentialsProvider currently accepts a V1 provider. Maybe that's fine and consumers can find a way to translate their V1 provider into a V2?

2. Updating the current AwsKmsClient to support both API types

All of the types (e.g. AwsCredentialsProvider) are different between the two API versions so the implementation will likely become very bloated. Also this increases the Jar size.

Additional context

I have a relatively simple working PoC made already that I would be willing to tidy up to contribute if my proposed solution sounds reasonable.

Also happy to chat about this if you'd like, feel free to reach out internally.

[ghost]

+1 on this - extra benefit of AWS SDK v2 is the support for k8s ServiceAccount-aware credentials provider (enables granting granular permissions on KEKs to individual pods).

[juergw]

Thanks for reporting this. This is certainly something we will need to look at. But we also plan to do other changes to the Tink's KMS API. So this may take some time.

[notnarb]

As a quick update my implementation using v2 of the SDK is now open source and can be found at https://github.com/privacysandbox/control-plane-shared-libraries/tree/main/java/com/google/crypto/tink/integration/awskmsv2 (permalink)

But we also plan to do other changes to the Tink's KMS API. So this may take some time.

👍 I would love to see this code upstream to get more eyes on it and remove the need for us to maintain it but we are unblocked right now.

Since this code is Apache licensed, others can probably unblock themselves by referring to this implementation.

---

Also included (but maybe doesn't make sense to upstream?) are simple API-backed implementations of PublicKeySign and PublicKeyVerify

[juergw]

Great, thanks for letting us know!

[danielharasymiw-wf]

@juergw Is there any movement on this? With the deprecation of v1 at the end of 2025, we're looking at migrating our usages of the v1 sdk to the v2 already.

Other than the deprecation, adoption of the v2 api is also important since the v1 aws sdk doesn't support FIPS.
https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html