Apps/WebApplicationReceipt: Difference between revisions

Jump to navigation Jump to search

Apps/WebApplicationReceipt (view source)

Revision as of 18:14, 28 September 2012

331 bytes removed ,  28 September 2012
no edit summary
(Privacy changes)
No edit summary
Line 56: Line 56:
=== the verify field ===
=== the verify field ===


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 <tt>verify</tt> field is a URL.  This can be used for automated verification of a receipt by application receivers and is encourage.  See "Interaction with the verify URL", below.


=== the reissue field ===
=== the reissue field ===
Line 96: Line 96:


# 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
# Checking the validity of the receipt with the issuer


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.
If a payment provider offers 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 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 a payment provider offers 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 receipt.
The Mozilla Marketplace will have a privacy policy about what is logged when a receipt is verified.  


=== 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. 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.
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.  
 
Currently checking the receipt validity with the issuer is the only way to confirm the status of the payment with the issuer. In future version of the receipt we 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:
The return value of this request is a JSON object with fields:
Amckay
Confirmed users
1,158

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/474799"

Navigation menu