39
edits
Apps/WebApplicationReceipt: Difference between revisions
Jump to navigation
Jump to search
Privacy changes
(Privacy changes) |
|||
| Line 9: | Line 9: | ||
* <tt>typ</tt>: MUST be the string <tt>"purchase-receipt"</tt> | * <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>product</tt>: A JSON object identifying the product the receipt covers and any store specific data. | ||
* <tt>user</tt>: A JSON object containing an | * <tt>user</tt>: A JSON object containing an identifier that the issuing store can use to identify the user associated with this receipt. | ||
* <tt>iss</tt>: A full domain (scheme, host, and port) for the store that issued the 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 | * <tt>nbf</tt>: A "not-before" timestamp (seconds from 1970-01-01T00:00:00Z in UTC, RFC3339), indicating when the purchase was completed | ||
| Line 27: | Line 27: | ||
=== the user field === | === the user field === | ||
The <tt>user</tt> field provides an | The <tt>user</tt> field provides an identifier that the issuing store can use to identify the human user associated with this receipt. There is no requirement that any other actor be able to validate this field, or use its contents. It is a JSON object structure, containing the following fields: | ||
* <tt>type</tt>: A string | * <tt>type</tt>: A string | ||
* <tt>value</tt>: A string | * <tt>value</tt>: A string | ||
The default supported value of | The default supported value of <tt>type</tt> is <tt>directed-identifier</tt>, and <tt>value</tt> is a unique user ID. To protect user privacy, the <tt>user</tt> field should not be an email address, or another identifier that the user or anyone else might recognize. Instead, the suggested implementation is to randomly generate a GUID for each transaction. The store should retain the GUID, and use it to link receipts to accounts, but it should be an unusable opaque identifier to all others. | ||
=== the iss field === | === the iss field === | ||
| Line 68: | Line 56: | ||
=== the verify field === | === the verify field === | ||
The <tt>verify</tt> field is a URL. | The <tt>verify</tt> field is a URL. 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 === | === the reissue field === | ||
| Line 83: | Line 71: | ||
}, | }, | ||
user: { | user: { | ||
type: " | type: "directed-identifier", | ||
value: " | value: "4fb35151-2b9b-4ba2-8283-c49d381640bd" | ||
}, | }, | ||
iss: "https://appstore.com", | iss: "https://appstore.com", | ||
| Line 109: | Line 97: | ||
# Verifying the cryptographic integrity of the receipt itself | # Verifying the cryptographic integrity of the receipt itself | ||
# Authenticating the identity of the user presenting the receipt | # Authenticating the identity of the user presenting the receipt | ||
Checking the validity of the receipt with the issuer is strongly discouraged. | |||
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. | 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. | ||
| Line 119: | Line 108: | ||
=== Interaction with the <tt>verify</tt> URL === | === 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. | 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". | * <tt>status</tt>: A string, containing one of the values "ok", "pending", "refunded", "expired" or "invalid". | ||