Confirmed users
1,158
edits
Apps/WebApplicationReceipt: Difference between revisions
no edit summary
RyanTilder (talk | contribs) (Add an explicit list of supported URL schemes) |
No edit summary |
||
| Line 13: | Line 13: | ||
* <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 | ||
* <tt>iat</tt>: An "issued-at" timestamp (seconds from 1970-01-01T00:00:00Z in UTC, RFC3339), indicating when this receipt was issued | * <tt>iat</tt>: An "issued-at" timestamp (seconds from 1970-01-01T00:00:00Z in UTC, RFC3339), indicating when this receipt was issued | ||
* <tt>exp</tt>: (optional) An "expiry" timestamp (seconds from 1970-01-01T00:00:00Z in UTC, RFC3339), indicating when this receipt will | * <tt>exp</tt>: (optional) An "expiry" timestamp (seconds from 1970-01-01T00:00:00Z in UTC, RFC3339), indicating when this receipt will expire | ||
* <tt>detail</tt>: (optional) A URL that contains additional human- or machine-readable detail about the purchase | * <tt>detail</tt>: (optional) A URL that contains additional human- or machine-readable detail about the purchase | ||
* <tt>verify</tt>: (optional) A URL that can be used by an authenticated application to verify a receipt | * <tt>verify</tt>: (optional) A URL that can be used by an authenticated application to verify a receipt | ||
| Line 130: | Line 130: | ||
The verify URL will always return 200 for a successful check. Other possible response codes are 500 (server error) or a 503 (server busy). In the case of a 503, the client should retry at a later date. Clients should not assume that a 503 is a sign that the receipt is invalid. | The verify URL will always return 200 for a successful check. Other possible response codes are 500 (server error) or a 503 (server busy). In the case of a 503, the client should retry at a later date. Clients should not assume that a 503 is a sign that the receipt is invalid. | ||
== Firefox Marketplace receipts == | |||
Receipts issued by the Firefox Marketplace receipts differ from the spec in that they contain two parts. The receipt is split on a tilde (~). The second half is the receipt as discussed in this document. The first half of the receipt is a JSON Web Key: | |||
{u'exp': 1384565449, | |||
u'iat': 1353029449, | |||
u'iss': u'https://marketplace-dev-cdn.allizom.org/public_keys/test_root_pub.jwk', | |||
u'jwk': [{u'alg': u'RSA', | |||
u'exp': u'AQAB', | |||
u'kid': u'signer.dev.addons.phx1.mozilla.com', | |||
u'mod': u'AO4UtZW...'}], | |||
u'nbf': 1353029449, | |||
u'price_limit': 100, | |||
u'typ': u'certified-key'} | |||
The fields are: | |||
* <tt>jwk</tt>: The JSON Web Key token | |||
* <tt>iss</tt>: A full domain (scheme, host, and port) for the store that issued this JSON Web Key | |||
* <tt>nbf</tt>: A "not-before" timestamp (seconds from 1970-01-01T00:00:00Z in UTC, RFC3339), indicating when the transaction was completed | |||
* <tt>iat</tt>: An "issued-at" timestamp (seconds from 1970-01-01T00:00:00Z in UTC, RFC3339), indicating when this transaction was issued | |||
* <tt>exp</tt>: (optional) An "expiry" timestamp (seconds from 1970-01-01T00:00:00Z in UTC, RFC3339), indicating when this transaction will expire | |||
* <tt>price_limit</tt>: always 100 | |||
* <tt>typ</tt>: always "certified-key" | |||
== References == | == References == | ||
* [http://self-issued.info/docs/draft-jones-json-web-token.html JSON Web Token] | * [http://self-issued.info/docs/draft-jones-json-web-token.html JSON Web Token] | ||
* [http://tools.ietf.org/html/draft-ietf-jose-json-web-key-14 JSON Web Key] | |||
* RFC 3339: Date and Time on the Internet: Timestamps | * RFC 3339: Date and Time on the Internet: Timestamps | ||