Emile Cormier

> (note the added 'not'). @estan, oops, yes, there was a "not" missing. > In point 6 and 7, there's a difference in phrasing: "must not send message types" and...

Come to think of it, Item 4 could also be a configurable policy on the router.

I'm adding this as a "corollary" to item 5: 5.1 Client implementations **should** return the `WELCOME.Details.roles` dictionary back to the application. The application can then make the determination whether or...

Submitted PR #178. Further refinement can be discussed in there, if desired.

Perhaps WAMP should be agnostic about the key derivation function (KDF), and this should be left as an implementation detail of the WAMP router or dynamic authenticator. This would make...

Experts now seem to be recommending stronger KDFs that are harder to crack on GPU/FPGA/ASIC: https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016 Namely, Argon2, bcrypt, and scrypt, with PBKDF2 as the least preferable (but still acceptable...

There are indeed safer alternatives to passwords, but WAMP shouldn't be imposing a restricted set of authentication schemes on its implementors/adopters. We shouldn't be dictating the business requirements and security...

Perhaps WAMP-CRA should be left alone as a "legacy" authmethod so that we don't break backwards compatibility. The ticket authmethod might already be sufficiently "pluggable" for most password schemes and...

[Section 6.1 Extensibility](http://wamp-proto.org/static/rfc/draft-oberstet-hybi-crossbar-wamp.html#extensibility) already permits implementation-specific keys in the Options/Details dictionaries. So an implementation making use of `CHALLENGE.Details` for ticket-based auth is not in violation of the WAMP spec, I...

Please educate me on the rationale for using PING/PONG messages over the `SO_KEEPALIVE` socket option? Is it to have an interval that's configurable on a per-socket basis?