In StoreContext.GetCustomerCollectionsIdAsync, does publisherUserId only embed metadata, or enforce binding to the Store customer?

Question

I am using the StoreContext.GetCustomerCollectionsIdAsync(serviceTicket, publisherUserId) API in a UWP app.

Microsoft documentation says the publisherUserId parameter can be used to “associate your ID with the new Microsoft Store ID key.”

I understand that Microsoft always returns a Collections ID key for the signed-in Store account, regardless of the value of publisherUserId.

My questions:

1. What exactly does “associate” mean in this context?
2. Is the publisherUserId embedded in the key only for publisher-side metadata, or does Microsoft use it to enforce any binding between the Store customer and the passed ID?
3. If the Collections ID key gets renewed after ~30 days, does the association with the previously passed publisherUserId persist in any way, or is it only embedded in the key that is currently valid?

Answer 1

Hello @Muhammed Işık ,

To address your questions:

1. What exactly does "associate" mean in this context?

The publisherUserId is embedded as a claim inside the JWT (JSON Web Token) that is returned as the Collections ID key. According to the documentation, when the key is decoded, it contains a claim called https://schemas.microsoft.com/marketplace/2015/08/claims/key/userId which contains "the same value that you pass into the optional publisherUserId parameter."

2. Is it only metadata, or does Microsoft enforce binding?

It's metadata only - the publisherUserId does NOT enforce any binding between the Store customer and your ID. The documentation explicitly states:

"An anonymous ID that identifies the current user in the context of services that you manage as the publisher of the current app. If you maintain user IDs in the context of your services, you can use this parameter to associate your ID for the current user with the new Microsoft Store ID key (the user ID will be embedded in the key). Otherwise, if you don't need to associate a user ID with the Microsoft Store ID key, you can pass any string value."

The point is: Microsoft always returns a Collections ID key for the signed-in Store account, completely independent of what you pass as publisherUserId. Microsoft doesn't validate or enforce that the publisherUserId matches the Store customer - it simply embeds your value in the token for your own tracking purposes.

3. Does the association persist after key renewal (~30 days)?

No, the association does not automatically persist. When you renew the key (after ~30 days), you would need to pass the same publisherUserId again if you want it embedded in the new key. The publisherUserId is only embedded in the specific JWT token you're creating - it's not stored separately by Microsoft to be automatically reapplied on renewal.

I hope this clarifies.

Answer 2

In this context, “associate” means that Microsoft allows you, as the publisher, to pass your own identifier (publisherUserId) alongside the request for a Collections ID so that you can link your internal user identity to the Collections ID generated by the Store. This association is primarily for your own tracking or analytics purposes. The Collections ID itself is always issued by Microsoft and represents the signed-in Microsoft Store account. Microsoft does not use the publisherUserId to enforce authentication or access; the Collections ID is valid regardless of what value you pass as publisherUserId. It is not a security token tied to your user ID—its purpose is to let you correlate the Collections ID with your internal user records if you choose to store that mapping.

The publisherUserId is embedded in the Collections ID in a way that your backend systems could use to recognize the association. However, the value is not part of the security or enforcement mechanism in the Microsoft Store itself; it doesn’t prevent someone else from using the Collections ID or affect how Microsoft validates the account. It is effectively metadata that the publisher can use to maintain continuity between their internal user identifiers and the Microsoft Store account.

When a Collections ID is renewed, the new key does not automatically carry forward a direct link to the previous publisherUserId. Each issued Collections ID is independent, and any metadata embedded or associated with the previous key is not guaranteed to persist. If you need to maintain continuity between your internal user ID and the renewed Collections ID, you should store the mapping on your side and update it whenever you receive a new Collections ID. The publisherUserId you pass with the renewal request can be the same as before, but Microsoft treats it as a fresh association for that particular issued key.

---

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Answer 3

In the context of the StoreContext.GetCustomerCollectionsIdAsync method, the term "associate" refers to the ability to link the publisherUserId you provide with the Microsoft Store ID key that is generated. This means that the publisherUserId is embedded in the key, allowing you to identify the user on your side when you receive the key back from the Microsoft Store. However, it does not enforce any binding between the Store customer and the publisherUserId in a way that would restrict or limit access based on the publisherUserId value.

To address your specific questions:

1. The publisherUserId is primarily for your own metadata purposes. It does not enforce any binding between the Store customer and the passed ID; Microsoft will always return a Collections ID key for the signed-in Store account regardless of the publisherUserId value.
2. If the Collections ID key is renewed after approximately 30 days, the association with the previously passed publisherUserId does not persist. Each key is independent, and the publisherUserId is only embedded in the currently valid key. When you renew the key, you would need to pass the publisherUserId again if you wish to maintain that association for the new key.