Closed indomitableSwan closed 2 years ago
Looks good to me! I just had two general things:
- question: Why are the server outputs in cryptographic_flows not whatever the server returns to the client (instead of just the success indicator)?
Good question. I didn't include those outputs because the server shouldn't be doing anything with those values at that point in the protocol, i.e., I included a success indicator because that seemed useful for server logging, debugging and security.
We could also have the outputs be whatever the server is supposed to store, but I didn't do this because storage happens at different places in the protocol execution, and ideally, the server doesn't wait to take those actions.
What would you recommend here?
- nit: could you update the links to the "retrieve_storage_key" section? I think we want "#retrieve_storage_key-protocol" instead of "#retrievestoragekey-functionality". Thanks!
Will do.
Good question. I didn't include those outputs because the server shouldn't be doing anything with those values at that point in the protocol, i.e., I included a success indicator because that seemed useful for server logging, debugging and security [...]
The success indicator makes sense! It would be nice to add what the server returns to the client as an output, but that may mess with the way you have the steps written out right now. I think both ways make sense, so I'll leave that up to you!
OK, I'll leave this as future conversation then. I'm always a little unclear of what the best ways are of handling these things --- still not sure why we would want to have server outputs that the server then doesn't do anything with. Is it for testing? Maybe that's more of an implementation detail than something the protocol writeup needs to be prescriptive about?
Otherwise, looks good, thank you!
Closes #98.