Credentials Client and Server are deleting TokenB about ocpi-toolkit

[lilgallon]

Yes you are right I forgot that part. I really like this approach of storing two tokens, one being ours, and the other one being theirs. I don't know why I didn't think of it... It removes the hassle of picking the right token at the right time.

It will be fixed this in the next version. Thanks again for your feedback

[lilgallon]

It's fixed in https://github.com/IZIVIA/ocpi-toolkit/releases/tag/R-0.0.14 for ocpi 2.2.1. This version is the priority right now, but the changes will be made on 2.1.1 & 2.1.1-gireve later on

[lilgallon]

Thanks for your feedback, you are absolutely right. The receiver has to use Token B to communicate with the sender. There was also a discussion about that here: ocpi/ocpi#166

So:

• As a receiver, the token B has to be kept, and the generated token C should not.
• As a sender, the generated token B should not be be kept, and the token C should be kept.

Then, to know which token to use, there are two cases:

• The platform only has either token B or token C. In that case, use the one that exists
• The platform has both of them. Because at some point both systems registered with the other. I am not sure about the solution yet. In that case, the caller knows if the call is made as a receiver or a sender. So I guess that the lib should offer the possibility to choose the token to use for the call. that's completely wrong

In clients, a solution would be to add a parameter that specifies who ou are when you call the other platform:

• the receiver (in that case use token B)
• the sender (in that case use token C)
• guess (use the token that exists, if both exists use token C)

all these statements are completely wrong..

[atschabu]

you always need to keep B and C .. because you need one to verify the incoming requests, and the other to send requests.

I think it might be easier to use something along the lines of 'our token' and 'their token' instead of B / C, as B and C is relative to whether you were the receiver or sender, while Ours and Theirs would be absolute from server / client perspective

This way a server will always compare authorization header against "their token" and a clients will emit "our token"

essentially the registration part would always store the 'received' token (be it B or C) as "our token" and the one it generates and transmits as "their token"

alternative names would be
our token / client token / request token
their token / server token / response token