@adrianhopebailie Thanks for your post - very helpful.
I think you’re right - maybe for clarity let’s qualify our usages (at least for this dialog, anyway) and say that a peer maintains “financial accounts”, each of which tracks some sort of financial position with a peer (e.g., a single net-balance, or some other balance-tracking mechanism).
Yes, this is correct, although I think our two definitions can co-exist.
I say this because overall I’m trying to arrive at is just an authentication mechanism (i.e., an identity and a credential to prove that identity) and my overall point (read below) is that there are many valid possibilities for a Connector to uniquely identify (i.e., authenticate) incoming connections.
This is not always true, and needn’t be always true.
For example, let’s imagine there are two companies, BigCo and SmallCo, and they want to “peer” with each other using ILP-over-HTTP.
For example’s sake, let’s say that BigCo has a database that stores a peerId for each of its peers, and so it has an entry in a database for SmallCo that is “sco”. Likewise, SmallCo has a database that stores peerId and SmallCo’s database has an entry for BigCo that is “bco”.
Now, let’s also imagine that BigCo is a sophisticated Connector operator, so they issue credentials that allow peers to operate across multiple financial accounts (for the sake of argument, we could imagine a token-authorization scheme that peers can utilize to get limited-access tokens to operate on one more more financial-accounts, depending on authorities granted in the token). We can also imagine that, in addition to offering complex permissions per-credential, BigCo also allows its peers to each hold multiple credentials so that some of its peer’s employees can use the BigCo connector with limited access, whereas other credentials might provide broader access (e.g., an “admin” account and a “payor” account).
Now, let’s also imagine that SmallCo is not quite so sophisticated, and when SmallCo issues a credential to BigCo, the credential is just a very simple shared-secret that only works with a single financial account at SmallCo.
While I agree that your domain-model accurately describes BigCo and SmallCo as “peers”, the auth-credentials they utilize are orthogonal to this concept. BigCo is providing one or more identities to SmallCo that transcend the concept of a financial account or a peer. Conversely, SmallCo is providing an identity that is strongly tied to one, and only one, financial account (ignoring the peer identifier entirely).
In this example, saying that the “subject” of the authentication credential is “the peer id” is just incorrect. In neither example at BigCo nor SmallCo are credentials identified with “sco” or “bco”. Instead, the “subject” of the authentication credential is something else, and it’s not always the same even between two peers due to the nature of ILP-over-HTTP.
All that so say: I’m not saying you’re peerId-as-Auth-Identifier is “wrong” in and of itself (quite the opposite, it could be a valid auth-scheme if two peers desired it). Instead, I’m saying that it would be a mistake to mandate this auth scheme on every bilateral peer relationship. It doesn’t need to be normalized.
I think as a non-normative suggestion, this is fine if it fits the auth-model between two peers.
However, as a normative part of the spec, this breaks down if the two peers don’t identify themselves using their peer identifiers (assuming these identifiers even exist between two peers).
All that to say, I think we should either close https://github.com/interledger/rfcs/pull/525 or else introduce a new section that details (non-normatively) how peers might use extra headers to help with authentication.
As one final example, the Java ILP-over-HTTP implementation supports a JWT authentication mode where the entire token can trivially be used in a performant manner without any additional headers. This is proof enough that this header is only sometimes required.