Add support for application addresses with whitelisting

This has to do with governing which addresses a gaia hub will accept writes on behalf of, which is a necessity for operating private hubs (https://github.com/blockstack/gaia#private-hubs)

Currently, the config.json file governs address whitelisting in Gaia. If a user wishes to restrict the set of addresses which can write to the gaia hub, this can pose a major usability issue.

Basically, if you want to whitelist an “identity address” like aaron.id’s 1EJh2y3xKUwFjJ8v29a2NRruPJ71neozEE – you cannot actually derive, say, my application address for app foo from the ID (or even the xpub, because these are all bip32 hardened indexes)

There’s a couple of approaches we could take:

1. Add endpoint to the gaia hub which will allow the blockstack-browser to modify the whitelist. This would require the notion of “admin addresses” which can modify the whitelist (you wouldn’t want applications, for example, to have this access)

2. blockstack.js attaches a “proof” in the authentication header on gaia hub writes. This proof would show that the app address is derived from the identity address. The auth response token already proves this fact (by signing the JWT with the identity key, and including the app private key) — however, this would require (1) sharing the auth response token and (2) the app’s transit key, which we should not do. Instead, we’d probably want to include this as a new field in the auth response as a JWT with payload = { appPublicKey, identityPublicKey } and signer = identityPublicKey

I’m in favor of (2), as that’s probably the simplest to implement, and it keeps the gaia hub basically stateless (you would just whitelist identity addresses, and then the application addresses for those identities would follow from there.)

Would love to hear thoughts on this – tagging some people who I remember having views on this: @jcnelson @jackzampolin @larrysalibra @cwackerfuss

[kantai]

First, the application is signing the “proof” JWT with the app private key, right? I’m not clear on how the “proof” is generated by blockstack.js. I’m not sure why signer = identityPublicKey here.

The “proof” is a signed assertion that a given public-key-hash is a child of the signer’s pub-key-hash, which should be the identity address.

For example, an assertion that 1Jrfd4ZHTd7ks5PdRHzBvmehZZVFvUFobR is a child of 16LPutBwZQXy9BypANh1q2y5Z5fpwrmifp (which you can find out from my profile.json-- https://core.blockstack.org/v1/users/aaron.blockstack_berlin.id) – you need to be able to do this if you want to run a gaia hub which only authenticates requests from “16LPutBwZQXy9BypANh1q2y5Z5fpwrmifp” and also it’s child-keys.

Second, regardless of how it is generated, could the “proof” be used by a malicious actor to replay a write operation? I’d recommend that the “proof” should have a monotonically-increasing timestamp and a short-lived lifetime to prevent reuse (e.g. no more than 30 seconds). The Gaia hub should NACK a request if its timestamp is lower than the last-seen timestamp (or is over 30 seconds old).

We currently use really long lived tokens – I agree this is a problem, and should be addressed, but I think that’s somewhat separate – here I’m not trying to authenticate, I’m just trying to get the gaia hub to associate an app address with a given identity address.

[jcnelson]

This has shipped!