Changes

Jump to: navigation, search

Apps/WebApplicationReceipt

331 bytes removed, 18:14, 28 September 2012
no edit summary
=== the verify field ===
The <tt>verify</tt> field is a URL. Although this is strongly discouraged, it This can be used for automated verification of a receipt by application receiversand is encourage. See "Interaction with the verify URL", below.
=== the reissue field ===
# Verifying the cryptographic integrity of the receipt itself
# Authenticating Checking the identity validity of the user presenting receipt with the receiptissuer
Checking Verifying the validity receipt is according to the usual rules of the receipt with JWT verification. Public key discovery for the issuer is strongly discouragedout 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 If a payment providers through well-documented means, and that the provider offers a <tt>issverify</tt> field will be used URL in the receipt, the verifying party is allowed to query that URL to pick a public key from a previouslydetermine the real-retrieved listtime status of the receipt.
Authentication of the user is dependent on the user identification contained in the <tt>user</tt> field. At this writing, the only supported user identification technique is a verified email address delivered through BrowserID. BrowserID-savvy application runtimes will use the [[BrowserID Directed Identity Assertion]] API to allow verifying parties to retrieve a user assertion without requiring a consent popup during application launch.=== Mozilla Marketplace Privacy Policy ===
If The Mozilla Marketplace will have a payment provider offers privacy policy about what is logged when a <tt>verify</tt> URL in the receipt, the verifying party is allowed to query that URL to determine the real-time status of the receiptverified.
=== 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  Currently checking the receipt using validity with the verify URL issuer is strongly discouraged for privacy reasonsthe only way to confirm the status of the payment with the issuer. Instead, applications should check the cryptographic validity In future version of the receiptwe hope to address this to provide more privacy for users by reducing the number of server checks.
The return value of this request is a JSON object with fields:
Confirm
1,158
edits

Navigation menu