URL encoding the secret solved it:

    var encodedSecret = System.Web.HttpUtility.UrlEncode(_clientSecret);
    var requestBody = $"grant_type=client_credentials&client_id={_clientId}" +
                                  $"&client_secret={encodedSecret}" +
                                  $"&resource={audience}";

Instructions for implementing trial version of the app refers devs to ExpirationDate field, but this field returns year 9999 for free apps and unlimited trials. Time limited trials are very limited in options and very strict as they don't allow users to start the app at all.

In order to implement more flexible trial version, devs need the start date, but devs cannot easily establish when the user acquired the app. One can try to store something locally (unreliable, not multi device aware), or use a web service (expensive, complex, privacy issues).

Best solution is for store to expose "license acquired date".

This would free devs to have more flexible trial version solutions without adding cost or complexity. For example, have a free app with a month honeymoon period after which some features are blocked or nagging to pay starts.

Can you please add this?

This would fit well with "dev friendly store" win11 announcement!

https://docs.microsoft.com/en-us/windows/uwp/monetize/exclude-or-limit-features-in-a-trial-version-of-your-app#step-4-get-an-apps-trial-expiration-date

In Store Services Client, the response body is not retrieved, as an exception is thrown when IsSuccessStatusCode is false. Consider attempting to retrieve the body anyway, as the body often contains useful information about why the query failed.

I know this isn't a very specific issue, but it seems like this repository is in very early development, so I thought I list a few questions I have here.

1. Will this be made into a NuGet package?
2. Why are you using the old-style v1.0 Azure auth rather than the new v2.0 version?
3. There are some differences between the parameters used here and documented here - https://docs.microsoft.com/en-us/windows/uwp/monetize/query-for-products. I notice you are using a 'v8.0' rather than v6.0. Is the v8.0 API documented anywhere?
4. I couldn't find the equivalent of the purchaser property returned by the collections API in v6.0. Is there one? In particular, I am planning to make use of the identityValue field, because I am hoping that this is non-spoofable assuming that it is embedded into the user key on creation and properly signed, although I'm not 100% sure about this.
5. Do you plan to make it easier to use access token caching for a service that is managing more than one app (i.e. could the access token cache optionally have a tenant Id and app Id as part of the cache key)?

I appreciate that this is probably the wrong repository for this, and you are probably not in a position to act on this request, but here it is anyway.

It would be great if the StoreContext provided a way of getting a unique identifier for the user currently signed in to the Store. This should also be embedded in the Microsoft Store User ID token (which is signed) in a way that cannot be spoofed. This can be specific to the publisher, if if necessary specific to the app. I don't see why this would be a breach of privacy for the user if it was a publisher-specific ID. I am also fairly sure this is technically possible, although may be a bit of work.

The reason I want this is slightly long-winder, but I'm sure there are also simpler scenarios that would benefit. Basically, one advantage of using the Store for purchases is that the user does not have to sign in (because generally they are always signed in to their Microsoft account). Therefore it's nice to be able to manage things without requiring a sign-in.

In my case I am actually trying to do something that should be quite simple but is really very complicated. Basically I want to user to retain access to an addon they purchased through the Store even if they sign out of the Store. I am willing to assume that the the user cannot edit my app code or Windows code, but they can view my app code. Therefore what I want is to sign a license containing a device identifier (obtained usingSystemIdentification.GetSystemIdForPublisher) and addon identifier with a private key (not embedded in the app), which can be verified with a public key embedded in the app. Moreover, it's necessary to limit the number of devices per addon purchase to something like 10. It is actually surprisingly difficult to implement this seemingly common requirement (and in fact I think it should be made even easier than the improvement I am suggesting here). In order to do this it seems I have to use the Microsoft Store services API to get the addon entitlement on my server and then sign it for a device and send the license back to the client. I am using the transaction ID plus product SKU ID to identify the individual addon purchase for the purposes of limiting the licensed devices to 10, although not sure if that's best. Due to the lack of a user ID, I have to using the transaction ID as the 'owner'. This is quite awkward when it comes to allowing the user to delete a device license (in case they are no longer using that device), because in order to determine ownership I have to query for the user's licenses from the Store, then see if the transaction ID is contained in the result. A user ID would be of great help here.

Hi @CameronGoodwin,
Introduction
In the last 2 days I've been revising some todos that aren't done yet, and tried to ping @hickeys to get any conclusion regarding this issue. I do understand posting in Microsoft Docs is not the right spot to raise issues because this is a thing related to services and not the docs. Either way, in my opinion, some documentation look a quite draft here. So, to sort things out, I'm coming to you in hope you can help me understand/point me to the right direction.

Explanation
I'm trying to use Certificates instead of Secrets to request access tokens so the client can use them on getting the Store Id Key.
I'm getting 2 different tokens for collections and purchase endpoints but both are returned in a v1.0 format. I specifically set the manifest of my entity in App Registrations with the value: "accessTokenAcceptedVersion": 2

I came with this conclusion after raising this issue and this issue. Both are closed because this looks like to a service issue, and we may need warn several teams.

The endpoint https://collections.mp.microsoft.com/v7.0/beneficiaries/me/keys, which is used by the Windows SDK, requests the Store Id Key but returns an error when the request is made with token that was issued with a certificate. That token contains the value appidacr=2, i checked myself before publishing here. Also, appidacr is claim from v1.0. This endpoint requires the use of appidacr=1. This claim is a requirement for v1.0 tokens.

Access Token returned by AAD

Endpoint used by the Windows SDK to get the Store Id Key

My insights

I took a look on your code, and this code snippet shows you are following the doc.

var requestUri = $"https://login.microsoftonline.com/{_tenantId}/oauth2/v2.0/token"; var httpRequest = new HttpRequestMessage(HttpMethod.Post, requestUri.ToString()); var requestBody = $"grant_type=client_credentials&client_id={_clientId}" + $"&client_secret={encodedSecret}" + $"&scope={audience}/.default";

Sorry for the long post, and links... but can you help me out/comment/alert the teams if this is an issue?

Tracking ID is required by the API to be a Guid, so perhaps should be typed as such.

I am trying to do a very basic thing: Use Microsoft Store. And I can't. This is unbelievably frustrating.

The download link points to a confirmation PDF. Can we get this fixed please? I don't want to use the online store, I want to use the app itself, which is strangely missing, as ubiquitous and intrusive as it normally is. Sigh.