"Ssl Hmac Channel Authenticator" performs the required authentication to start a Chrome Remote Desktop connection according to the traffic annotation tag at https://cs.chromium.org/chromium/src/remoting/protocol/ssl_hmac_channel_authenticator.cc?rcl=2e74bbd6578228836fba164e6653e64676609eca&l=52.

This is blocking the Canary launch of network service.

Can you point us at some documentation or sample CLs to help with this migration?

An example CL for the migration can be found at https://chromium-review.googlesource.com/c/chromium/src/+/1070434, where I migrated //extensions' socket APIs to mojo sockets.

For background on network service, you can find more information on this doc:
https://docs.google.com/document/d/1wAHLw9h7gGuqJNCgG1mP1BmLtCGfZ2pys-PdZQ1vg7M/edit?usp=sharing or at go/network-service

Thanks! There's no milestone attached to this bug, or the one it's blocking. What's your time schedule for this work?

+jam@ who can comment more on timeline 
We are aiming for a canary launch of network service in M69. 

Will someone from chromoting be able to help with the migration? There is a similar one in  Issue 848075  . 

M-69 is going to be tough given our existing priorities and team vacations, but I'll see what I can do.

How is your canary rollout going to work? I don't think any of the Chromoting code runs inside Chrome (it will be either host code, which is a separate binary, or client code, which runs as a PNaCl plugin) so as long as the old implementation exists, you can probably run your canary without us breaking you (or vice versa). We'll still need to do this work before the old implementation is deleted, but that gives us more time.

Ah, got it. Thanks for this context! 
Network service is only for Chrome binary at this point. Both chromoting's host and client PNaCl plugin won't be affected.
I will WontFix this and the other issue.

(the //net socket implementation will remain as they are and won't be deleted.)