> Only the server can calculate the HMAC in the verify_token. let's continue on this off list. overall concept is clear yet need to understand these details better to update the protocol.
> It may not be your use case then - I just got the impression from your spec > that you wanted zax to be agnostic to the underlying end to end message > protocol. > > But if you are linking the hpk to message protocol then it seems you want a > more integrated solution. yes, that's how it is currently - endpoint can *not* send a message without zax stamping originator hpk on it. in fact clients only provides 'to:hpk_dest', and zax stamps 'from:hpk_origin' from active session. Thus when message is recovered the destination knows the originator does own 'from:hpk' - otherwise zax wouldn't accept upload session on that hpk. So there is that lightweight binding of 'from, to' and opaque message blob on zax side. Thanks for the great discussion! that was a lot of good ideas to tighten the protocol. _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
