Key management for PICL users
Перейти к файлу
Ryan Kelly 155de68d91 Merge pull request #12 from mozilla/mysql_kvstore
Purges couchbase and adds mysql setup and configuration
2013-04-09 17:43:00 -07:00
config add mysql setup and configuration, purge couchbase 2013-04-09 16:30:02 -07:00
lib add mysql setup and configuration, purge couchbase 2013-04-09 16:30:02 -07:00
routes only accept either an email or an assertion 2013-03-07 15:24:07 -08:00
scripts/aws add mysql setup and configuration, purge couchbase 2013-04-09 16:30:02 -07:00
test clean up unused code in tests 2013-03-07 11:20:57 -08:00
.awsbox.json add mysql setup and configuration, purge couchbase 2013-04-09 16:30:02 -07:00
.gitignore initial keyserver implementation 2013-02-15 15:32:59 -08:00
.travis.yml configure travis for mysql 2013-04-09 16:41:06 -07:00
LICENSE initial keyserver implementation 2013-02-15 15:32:59 -08:00
README.md minor tweak so we can update the server on aws 2013-02-27 13:53:36 -08:00
index.js initial keyserver implementation 2013-02-15 15:32:59 -08:00
package.json add mysql setup and configuration, purge couchbase 2013-04-09 16:30:02 -07:00
server.js initial keyserver implementation 2013-02-15 15:32:59 -08:00

README.md

picl-keyserver

Key management for PICL users

API

You can currently create a new user account, add additional devices, and bump the class A key version.

All API calls take a JSON payload of an email address. E.g.:

{
  email: bob@example.com
}

or, for GET requests: ?email=bob@example.com.

Eventuall, they might take an assertion:

{
  assertion: <persona generated assertion>
}

NULL security model

Clients can safely ignore version and deviceId in API responses. These are intended for key revocation, but they won't be used in early prototypes.

POST /user

Creates a new user account and generates a class A key.

Returns:

{
  success: true,
  kA: <32 random bytes in hex>,
  version: 1,
  deviceId: <32 random bytes in hex>
}

POST /device

Registers a new device with the user account.

Returns

{
  success: true,
  kA: <user's current kA>,
  version: <kA version>
  deviceId: <newly generated deviceId>
}

GET /user[/deviceId]

Fetches the user's current key. deviceId is not required.

Returns

{
  success: true,
  kA: <user's current kA>,
  version: <kA version>
}

POST /user/bump/{deviceId}

Not used in NULL authentication model

This creates a new class A key for the user and bumps the version number. All devices besides the device that initiated the call will be marked as having an outdated key.

Returns

{
  success: true,
  kA: <newly generated kA>,
  version: <kA version>
}