Self-provisioned keys

[sabineschaller]

When a Rafiki instance calls out to other open payment endpoints, it needs to provide a key for getting a grant. This is required to identify itself. Hence, the Rafiki instance needs to provision its own key(s).

[wilsonianb]

Is there any reason to use unique keys for different auth servers / Open Payments servers?
i.e. should Open Payments server A use one key when acting as a client of Open Payments server B and a different key as a client of Open Payments server C (assuming they all have different auth servers)?

[wilsonianb]

Oh
https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-protocol#section-2.3

A client instance that is capable of talking to multiple AS's SHOULD
use a different key for each AS to prevent a class of mix-up attacks
as described in Section 12.29.

This makes me think that either:

• keys should be provisioned on the fly when interacting with an auth server for the first time
• we support (out of band?) client key pre-registration at the AS (also section 2.3):

The client instance's key MAY be pre-registered with the AS ahead of
time and associated with a set of policies and allowable actions
pertaining to that client.

[wilsonianb]

What if we still generate a single secret/key at startup, but use it to deterministically generate keys for individual auth servers?
https://crypto.stackexchange.com/questions/75614/securely-derive-aes-and-ed25519-keys-from-a-ed25519-seed

[wilsonianb]

We had a look at the attack that is described in the GNAP spec: https://elib.uni-stuttgart.de/bitstream/11682/12220/1/Security_Analysis_GNAP.pdf
We don’t think that Open Payments is susceptible to this attack as we bind the AS and RS (i.e. the RS tells the client which AS to use)
Nonetheless, we do think supporting multiple keys in future is good practice.