Just some quick thoughts on this as I've not had more than quick thoughts on this issue. This issue was about authentication for requests to gremlin server and not authorization as to what graphs one might have access to, but perhaps authorization is tied into this in some way. I hadn't thought that far ahead.
Users currently have methods open to them to implement their own authentication/authorization schemes. You just have to implement your own Channelizer implementation to inject your custom security handler and configure it in the yaml file. To some degree, I wonder if adding specific "authentication" and "authorization" extension points to Gremlin Server infrastructure can make that process any easier. For authentication, I suppose there could be some out-of-the-box security handlers for openid, ldap, whatever, and they could be configured via some secure implementation of a Channelizer or maybe even the existing ones somehow with new configuration capabilities there.
I don't think the protocol would have to change. I think we can just pass username/password as keys in the RequestMessage arguments...simple enough.
Going back to authorization, that's a bit more tricky because all graphs get bound to the ScriptEngine for every request. I suppose there would be room to have an authorization mechanism be consulted to determine which Graph and/or TraversalSource bindings were supplied given an authenticated user.