Thanks for taking my earlier comment into consideration. I appreciate
that it is now clearer which functionality needs to be implemented and
where.

Concerning the protection against abuse of the join proxy, I now
see that the message is:

       JPY_message =
       [
          pledge_context_message : bstr,
          content   : bstr
       ]

However, I also read about the 'header' and the 'content' fields.  Is
the pledge_context_message field the 'header'? If so, the document is
contradicting itself since in some parts it says what it contains
while in other parts it says pledge_context_message is entirely
implementation specific.

My understanding of the new design is that pledge_context_message
field effectively acts as a nonce and token, it is not protected and
likely even valid for multiple usages. If so, calling the result an
encrypted message is perhaps misleading since I may be able to replay
other messages once I have sniffed the pledge_context_message
value. The targets I may be possible to reach depends on how an
implementation chooses to implement pledge_context_message, the
specification only gives an illustrative example.

Anyway, this is an improvement, but perhaps it would be even better if
there would be a minimum requirement which information needs to be in
the token to prevent abuse of join proxies. But SECDIR people should be
the proper persons to judge this and whether it is find to trust that
implementations understand the significance of including enough
context information. Perhaps this should be discussed in the security
considerations to highlight the security implication of the choice of
the pledge_context_message content.