348
edits
Apps/WebApplicationReceipt/GenerationService: Difference between revisions
Apps/WebApplicationReceipt/GenerationService (view source)
Revision as of 21:21, 29 March 2012
, 29 March 2012→System Overview
| Line 12: | Line 12: | ||
The public keys are carefully exported from the HSMs and conveyed to a distribution point that provides 3rd parties with confidence (see Appendix B). | The public keys are carefully exported from the HSMs and conveyed to a distribution point that provides 3rd parties with confidence (see Appendix B). | ||
A horizontally-scalable cluster of receipt signing nodes receives one of these keys from the root nodes every day. These signing nodes are responsible for receiving unsigned receipts from the Marketplace, signing them, logging the fact of signing, and returning the signed receipt as the response. | A horizontally-scalable cluster of receipt signing nodes receives one of these keys from the root nodes every day. These signing nodes are responsible for receiving unsigned receipts from the Marketplace, signing them, logging the fact of signing, and returning the signed receipt as the response. | ||
The certification of a signing key will cover the key itself, its identifier, and the date range for which it is valid (as a nbf/exp pair, as defined in [http://tools.ietf.org/id/draft-jones-json-web-token.txt JSON Web Token]). | |||
When an authenticated user session makes a receipt request, the Marketplace issues a request-to-sign to the receipt signing cluster, logs the request, and returns the signed receipt to the user. | When an authenticated user session makes a receipt request, the Marketplace issues a request-to-sign to the receipt signing cluster, logs the request, and returns the signed receipt to the user. | ||
| Line 18: | Line 21: | ||
The user agent makes requests for receipts when Marketplace content uses the Application DOM API to request an install. The receipts are stored, along with application metadata, in the user agent, where they are made available to the developer's domain through the Application DOM API. The developer is then expected to upload the receipt to their own server, where they can perform validation. | The user agent makes requests for receipts when Marketplace content uses the Application DOM API to request an install. The receipts are stored, along with application metadata, in the user agent, where they are made available to the developer's domain through the Application DOM API. The developer is then expected to upload the receipt to their own server, where they can perform validation. | ||
Validation of the receipt can be done by the developer's server, by verifying the signature, and then verifying the chain of certificates. The root of trust of the chain will be one of the public certificates previously advertised by the Marketplace. | Validation of the receipt can be done by the developer's server, by verifying the signature, and then verifying the chain of certificates. The root of trust of the chain will be one of the public certificates previously advertised by the Marketplace. The date range on each key must be checked against the issue date on the receipt. If the application's server decides that the receipt is cryptographically invalid, it can take appropriate action. (XXX Can the server prompt the user agent to refresh the certificate? See appendix D). | ||
Alternatively, the developer can POST the receipt to a URL specified in the receipt (the verify_url). This is a service, hosted by Marketplace, which will: | Alternatively, the developer can POST the receipt to a URL specified in the receipt (the verify_url). This is a service, hosted by Marketplace, which will: | ||
| Line 27: | Line 30: | ||
(NB to Marketplace team: If there is going to be a developer-facing API to query the state of individual receipts by user ID, it will need to have a developer-facing authentication piece. This system does not require authentication; possession of the receipt is considered sufficient to find out the user's status). | (NB to Marketplace team: If there is going to be a developer-facing API to query the state of individual receipts by user ID, it will need to have a developer-facing authentication piece. This system does not require authentication; possession of the receipt is considered sufficient to find out the user's status). | ||
The user agent should endeavor to never present an expired receipt. This has obvious implications for the UA's behavior, and is developed in depth in Appendix D. | |||
== Software Components == | == Software Components == | ||