Investigate verifying EDDN Senders

[Athanasius]

A scheme has been proposed to know who is sending data to EDDN and thus give the ability to ban the game account if needs be.

1. Require a one-time Frontier oAuth2 verification on an EDDN server.
2. When that succeeds generate some form of token for the user. This will be passed back to the calling application (Sender <-> EDDN token server <-> Frontier oAuth2).
3. The Sending software will then set this token as extra information in the /upload/ request.
4. The EDDN Gateway will in some manner verify it's both a valid token and that the token hasn't been banned.

There are lots of details to work out with this. Some issues:

1. The user should not be able to simply re-initiate verification to get a new token. So the 'token server' would need to be storing something like the FID that comes back to know if to allow this or not. This FID is already readily available (along with actual PII) to any application performing Frontier oAuth2, or indeed the FID is right there in the Journal files in the Commander event.
2. Either the EDDN Gateway will need access to the list of valid tokens, or the tokens will need to be cryptographically verifiable in some manner. The Frontier oAuth2 'bearer tokens' themselves use such a scheme, being an RSA encrypted string (presumably the private key is only on the auth server and the CAPI servers have the public key in order to decrypt and verify them).
3. Third-party websites that retrieve CAPI data and send it to EDDN will need special handling. This could take the form of their tokens being special and site-wide. They're already taking the data directly from Frontier so there are no worries about its authenticity.
4. At least during the rollout phase, and there's no reason not to continue it later, the EDDN Gateway/Relay will add some indication of "this message is from a verified sender". Listeners can then use that indication when deciding whether or not to use the data.

[derrickmehaffy]

Wanted to point out, this is something Canonn had proposed many years ago and there was a passport package created just for Frontier: https://www.npmjs.com/package/passport-frontier

Since this is something we proposed a while ago, there was some concerns about GDPR and it's why we opted to enable our own "blacklist" system on the Canonn API previously. Personally I think it's a great idea and would go leaps and bounds to improve data integrity or at the very least to prevent abuse.

[robbyxp1]

It does not stop journal spoofing.

Its just a means of making it more painful for a detected scamster.

Only if EDDN spamming gets out of control we should implement it.

[inorton]

In order to prevent spoofing of data we'd need to tie the messages sent to EDDN with a verified FID, We'd need to get the sending app to generate a key and have it signed by the fdev authentication service and then have the sender sign the EDDN messages with this key. This would probably break GDPR because we'd be able to track the whole game session for a very long time.