348
edits
Apps/WebApplicationReceipt/GenerationService: Difference between revisions
Jump to navigation
Jump to search
Apps/WebApplicationReceipt/GenerationService (view source)
Revision as of 22:36, 28 March 2012
, 28 March 2012→Appendix C: Receipt Reissuance
m (→System Overview: added revocation check note) |
|||
| Line 79: | Line 79: | ||
When the user agent receives this error code, it must contact the issuing authority from which it received the receipt and request a fresh one. | When the user agent receives this error code, it must contact the issuing authority from which it received the receipt and request a fresh one. | ||
In the happy path, this could be as simple as making a GET request to a URL that was specified in the original receipt, and could be handled automatically and silently. In the less happy path, this could require authentication of the user agent to the issuing authority (e.g. Marketplace); if the user fails to authenticate, the receipt cannot be refreshed. | In the happy path, this could be as simple as making a GET request to a URL that was specified in the original receipt, and could be handled automatically and silently. In the less happy path, this could require authentication of the user agent to the issuing authority (e.g. Marketplace); if the user fails to authenticate, the receipt cannot be refreshed. This could also fail because the user does not actually have a valid purchase record; the common case is probably user account confusion (signed in as wrong user) but this is how the stolen-key case would manifest to the user as well. | ||
This interaction will require new logic in the user agent and should be communicated to the webapps and B2G teams for review. | This interaction will require new logic in the user agent and should be communicated to the webapps and B2G teams for review. | ||