39
edits
Changes
Privacy changes
* <tt>typ</tt>: MUST be the string <tt>"purchase-receipt"</tt>
* <tt>product</tt>: A JSON object identifying the product the receipt covers and any store specific data.
* <tt>user</tt>: A JSON object containing an independently-verifiable identifier for the user that made the purchase, or an anonymous identifier that plays issuing store can use to identify the same roleuser associated with this receipt.
* <tt>iss</tt>: A full domain (scheme, host, and port) for the store that issued the receipt
* <tt>nbf</tt>: A "not-before" timestamp (seconds from 1970-01-01T00:00:00Z in UTC, RFC3339), indicating when the purchase was completed
=== the user field ===
The <tt>user</tt> field provides an identification of a identifier that the issuing store can use to identify the human user associated with this receipt. There is no requirement that can any other actor be independently verified by the both the issuer and verifier of the receiptable to validate this field, or use its contents. It is a JSON object structure, containing the following fields:
* <tt>type</tt>: A string
* <tt>value</tt>: A string
The default supported value of <tt>type</tt> is <tt>email</tt>; the value, in this case, is a verified email address. ==== privacy-protecting receipts ==== To protect user privacy, a receipt can be issued to a user without identifying them by email address. For this purpose, <tt>type</tt> is <tt>directed-identifier</tt>, and <tt>value</tt> is a unique user ID. The unique To protect user ID should be scoped to the app's origin. In other words, a given user will show up as a different userID for each app she purchases. However, if a new receipt is issued to a user for a given originprivacy, then the <tt>directed-identifieruser</tt> field should remain not be an email address, or another identifier that the sameuser or anyone else might recognize. For Instead, the suggested implementation purposes, it is suggested that the userID be generated either as to randomly generate a random string stored by GUID for each transaction. The store should retain the marketplace once GUID, and kept indefinitelyuse it to link receipts to accounts, or deterministically as HMAC(secret, email || "." || origin) where the secret must but it should be stored indefinitelyan unusable opaque identifier to all others.
=== the iss field ===
=== the verify field ===
The <tt>verify</tt> field is a URL. Is Although this is strongly discouraged, it can be used for automated verification of a receipt by application receivers. See "Interaction with the verify URL", below.
=== the reissue field ===
},
user: {
type: "emaildirected-identifier", value: "pseud4fb35151-2b9b-4ba2-8283-123gBm51jc56s@idprovider.comc49d381640bd"
},
iss: "https://appstore.com",
# Verifying the cryptographic integrity of the receipt itself
# Authenticating the identity of the user presenting the receipt
Verifying the receipt is according to the usual rules of JWT verification. Public key discovery for the issuer is out of scope for JWT, but it is expected that verifying parties will receive public keys from their chosen payment providers through well-documented means, and that the <tt>iss</tt> field will be used to pick a public key from a previously-retrieved list.
=== Interaction with the <tt>verify</tt> URL ===
If the <tt>verify</tt> URL is present, the receiving party may verify it by issuing a POST request to it, where the message body contains the complete receipt. Note, however, that verifying a receipt using the verify URL is strongly discouraged for privacy reasons. Instead, applications should check the cryptographic validity of the receipt. The return value of this request is a JSON object with fields:
* <tt>status</tt>: A string, containing one of the values "ok", "pending", "refunded", "expired" or "invalid".
