Release 4.2 source code to Github

[ShortRoundDev]

My organization received a notification that we needed to upgrade our UID2 Java SDK to 4.2 to avoid breaking changes. As far as I can tell, the existing UID2 SDK for Java (4.1 and below) does not completely implement the UID2 API (e.g: POST identity/map), and so we have implemented our own UID2 SDK.

I want to understand the changes from 4.1 to 4.2, but there is no corresponding github release for 4.2, even though the binaries have been released to the public repositories: https://central.sonatype.com/artifact/com.uid2/uid2-client

1. What changes are necessary to avoid breaking changes on September 30th? I understand some values are now Base64 encoded
2. Does the new 4.2 SDK implement the entire UID2 API, or still only token generation?

[sunnywu]

Hi @ShortRoundDev , apology for missing your message here.

We are still in the process of formulating the release documentation and therefore we haven't publicly documented the changes in our SDK.

The changes are:

• Use Base64URL encoding for the new Advertising Token v4 format which is URL friendly encoding.

• Therefore the most important changes you need is the decrypt method needs to support decrypting v3/v4 format tokens, please see com.uid2.client.Uid2Encryption#decrypt(java.lang.String, com.uid2.client.KeyContainer, java.time.Instant, com.uid2.client.IdentityScope) codes.

• Added a UID2 Sharing feature which adds a "com.uid2.client.UID2Client#encrypt(java.lang.String)" function to encrypt a raw UID2 into a v4 UID2 token.

The master of this open source repo has the latest source code (v4.2.4) so you can always refer to master for our latest releases

The latest Java SDK 4.2.4 still do not have the identity/map implemented.

I will bring your PR back to our team for further discussion.

Please let me know if you have further questions.

Thanks.

[sunnywu]

@ShortRoundDev may I ask what you/your company uses identity/map endpoint for? Just would like to see if we miss any use cases in our design of the SDK thanks.

[ShortRoundDev]

@sunnywu We operate a DMP, a DSP, and an SSP. Each component is a distinct workflow which is agnostic of the others:

DMP:
Clients provide us with user PII which we hash on the frontend (we do not store PII) before upload. We then use the POST identity/map endpoint to map those hashes to the UIDs, which we then use as keys within our user graph

DSP:
We receive encrypted UIDs (UID Tokens) from our bid stream, which we then decrypt and use as a key for our identity graph for ad targeting (this workflow is mostly coded but we are still working through the legal processes with Trade Desk)

SSP:
We send hashed user PII for users logged into client websites to our identity service to retrieve a UID token (encrypted UID), which we then submit to the bid stream (again, this workflow is mostly coded, but we are working on compliance with Trade Desk). We also happen to OWN that bid stream, but we only send the UID tokens from the frontend and never raw UIDs (compliant with the Trade Desk workflows).

[ShortRoundDev]

@sunnywu Can you confirm that raw UIDs (e.g: UIDs returns by the POST /identity/map endpoint are not going to be affected (e.g: only encrypted UIDs/UID tokens/Advertising Tokens)?

[sunnywu]

@ShortRoundDev hi yes identity/map isn't affected as this endpoint produce raw UID2 and we aren't changing raw UID2 format (just the ad token format that contains the encrypted raw UID2)

[GEverding]

Can we get this released so we can kill our custom code to build these payloads?

[jon8787]

We've recently added support for /v2/identity/map with the following features:

• Similar interface to the existing PublisherUid2Client / PublisherUid2Helper classes: IdentityMapClient / IdentityMapHelper
• Allow consumers to use their own HTTP library (e.g. async HTTP) via IdentityMapHelper, or use IdentityMapClient which uses OkHttp internally
• Ensure we only send hashed DII (emails, phones) to UID2 operator, even if the consumer provides unhashed DII
• If the user provides unhashed DII, the response keys returned by getMappedIdentities() will be the same unhashed DII (even though the response from UID2 Operator contains only hashed DII)
• Expected usage is shown in integration tests for valid and invalid emails, email hashes, phones, phone hashes
• Encryption implementation is reused between publishers and advertisers (and we plan to reuse for DSPs too)

Hopefully, the new APIs meet your needs. Please do reach out if you spot any gaps.