Has any thought been put around adding some level of Authentication to the Open DXL fabric? As of now we only know that applications/certificates/tags have authorization to specific services, however, the receiving end has no idea about WHO is sending these requests. A username would be quite helpful when requests are received so that a very bare minimum it could be tracked. With more and more items connecting to the fabric I believe the who will be just as important as the what. This could be done upon registration of the service and added to the request object prior to submitting a request to a service. Services that require authentication would need to have a session key in-order to submit the request and the receiving end would get the session key where it could look up the user information if needed (force some sort of state on the open dxl app as to limit the amount of data being sent with every response).
At this point (as you mentioned), the authentication to the fabric is certificate-based. Once a connection has been established, certificates or tags (if ePO-managed) are used to control what the particular connection can send or receive.
The identity on the fabric is the connection identifier. In ePO-managed fabrics this is the GUID of the McAfee agent that the connection was made on behalf of.
There have been a number of discussions regarding the enhancement of the fabric to provide a richer set of authorization models (use of tokens, etc.).
With the fabric as it stands today, you can develop your own session-based interaction model with services. The following thread post contains details about invoking the same service instance on the fabric (versus round-robin semantics):
Discussion Thread: Multiple services?
With the type on invocation model described in the link above, the service could provide its own authentication model, sessions, etc.