Enable canisters to make HTTP(S) requests

[paulyoung]

@JaMarco

Permissioned private APIs would be really hard. A canister dev would have to get permission/access to an company’s internal APIs which would probably involve giving out a password and saving it into nodes they dont control. On Chainlink the company controls the nodes that query their private APIs.

I think this shares the same concerns as authenticating with other services, and could potentially share the same solutions as well.

The solution I proposed for authenticating with push notification services (for example) was to use a threshold key pair (as in threshold ECDSA)

The private key is split into shares so no one sees the fully assembled private key but canisters can sign outgoing requests. Only the public key is revealed in the request.

Discussing A standard for push notifications and subscriptions in wallets

I think the main concern that was brought up during Friday’s call was that at least some push notification services require the caller to include sensitive information in the request, which would be exposed to nodes in the subnet and then boundary nodes. If a bad actor were able to obtain this information and impersonate a trusted application the results could be pretty disastrous. From what I can gather, Apple (specifically) generates a key pair for you. Storing the private key in a canister …

Discussing A standard for push notifications and subscriptions in wallets

It appears that Firebase can send push notifications. Firebase projects support Google service accounts which allow uploading the public key: You can upload the public key portion of a user-managed key pair to associate it with a service account. After you upload the public key, you can use the private key from the key pair as a service account key. However: The key you upload must be an RSA public key that is wrapped in an X.509 v3 certificate and encoded in base64. I don’t think Thresh…