Services/AppKeys

Goals

Mozilla App keys are designed to be a generic key to identify a 'valid' originating application.

They are intended to be:

• An identifier
• An assurance that the application remains in good standing

They are not intended to be:

• An endorsement by the Mozilla company or community of the third party (except where revocation of a key implies negative endorsement)
• A method for rate limiting

App keys need to be:

• Unique - obviously no two applications should have the same key unless the designer has chosen to do so. The key should be long enough to ensure plenty of keyspace.
• Rapidly verifiable - both for well-formedness and validity
• Cachable - the key should not be permuted on transactions, so that it can be locally cached for a period of time
• Revocable - by presenting appropriate credentials, the 3rd party app can pull a compromised key and have the server start reporting it as invalid.
• High-Availability - the verification service should be expected to have high uptime, as a non-response should be interpreted as approval of the key.

API Spec

https://appkey.services.mozilla.org/verify/<key>

Returns 1 if the key is in good standing, 0 otherwise

User interface

Mozilla account integration provides several advantages for users. It would be possible to do key revocation without it, but that would require us to adopt a forgot-password-style recovery flow, where you enter the value of the key and we send a message with a verification code that requires you to visit a web form, etc.

With Mozilla account integration, it's possible to provide some extra services that may be of value to 3rd parties, such as the ability to see all their keys (including status) in a single location, and add a brief description to each.

This will give users the opportunity to View, Add and Delete API keys through the account portal. With the addition of a login requirement, we no longer need to worry about pointless mass creation of API keys.

Information scheme

We should save the following information:

• Key: base32encoded 32-character string (giving us 160 bits of space)
• UIDNumber
• Brief Description (optional)
• Status': 1 (for valid) or 0 (revoked).

Given the likely number of App keys to be created, and the desire to be able to look up (rapidly) on Key and (slower) on UIDNumber, a MySQL table should be sufficient for initial work, as the total key volume is likely to fit into the mysql cache. A simple optimization would be to set up a memcache of key=>status that is also written to on changes. Dumping the contents into memcache in the event of a failure should be a pretty rapid process, and we can even do this process regularly to ensure consistency between the two data stores.