The specification does not state what to do when Permissions and Governance files contain "extra elements" that are not valid according to the XSD.

This is expected to occur both as a result of vendor extensions as well as due to additions in future versions of DDS Security.

Allowing these extensions/additions without breaking compatibility is important. So the spec should be clear in that they are allowed and also provide rules/guidelines on them.

Some possibilities:

• Simply state that elements that are not expected/understood should be ignored
• Same as above but provide some structure for those elements. E.g. specify that they must have a "vendorId" attribute (used to avoid collisions) and a "mustUnderstand" attribute used to force failure in some cases.
• Define an "extensions" element that has known structure (e.g. name/value pairs) which is the one used for the extensions.
• Others to be proposed.

Common approaches are described here: http://www.ibm.com/developerworks/library/x-xtendschema/
This document also discusses various approaches: https://www.xml.com/pub/a/2004/10/27/extend.html

The Authentication Plugin Model specifies a state machine to be implemented by the DDS middleware to manage the authentication of the remote Participants. The implementation of this state machine is complex because:

• It is not specified when to call validate_remote_identity (for each received SPDP or only for the first received SPDP from a newly discovered Participant? What if a malicious Participant send a SPDP at first, usurping the GUID of a legit Participant?)
• The handshake could be initiated from both sides at nearly the same time (nothing forbid this in §8.3)
• There is no indication in the specification to tell how parallel handshakes between 2 Participants should interact
• It is difficult to determine at which sense a received message belongs
• In §8.3.2.8.1 it's specified that "The DDS security implementation shall pass to the AuthenticationPlugin any message received by the BuiltinParticipantStatelessMessageReader...". But there are states in the state machine where it's not specified how to pass those messages (e.g. when validate_remote_identity has not been called yet, and the state machine is not initialized)

This results in quite complex code, and this is a weakness in a mechanism which needs to be very strong.

Anyway, the state machine in the middleware is redundant with the one needed in the plugin. In addition, it has to deal with events where it doesn't know what is really going on. Only the plugin has the real information. Therefore, we think this middleware state machine is useless, add extra complexity which makes the authentication less robust, and consumes a lot of resources.

Instead, we suggest to remove it and to change the mechanism to the following:

• remove all the "_handshake" methods on the Authentication Plugin
• add a treat_message method to the authentication plugin to handle any incoming authentication ParticipantStatelessMessage
• add a send_message method to the authentication listener interface to tell the middleware to send an authentication ParticipantStatelessMessage
• add a validated_remote_participant method to the authentication listener interface to tell the middleware that the indicated participant is authenticated
• add a invalidated_remote_participant method to the authentication listener interface to tell the middleware that the indicated participant is not authenticated
• once the authentication is initialised with validate_remote_identity, all the state machine is managed directly by the plugin which sends the appropriate messages and is given the received ones, until its decision is given to the DDS middleware through the authentication listener.

This will provide the necessary functionality in a much simple, efficient and robust manner.

An implementation of the built-in Cryptography plugin is not compatible with the local implementation of the built-in Authentication, unless it uses/understands the same type of SharedSecretHandle. (SharedSecretHandle is the interface defined at the architecture level.) Therefore, the two built-in plugins are tied together and you cannot replace one or another with any other implementation of the same built-in plugin.
It is possible to make them independent in two possible ways (at least):

1. Define a BuiltinSharedSecretHandle that extends SharedSecretHandle interface, and has 3 methods like this:
   • octet[] getChallenge1(): returns challenge1 from the authentication handshake
   • octet[] getChallenge2(): returns challenge2 from the authentication handshake
   • octet[] getSharedSecret(): returns the shared secret from the authentication handshake
2. OR define a new type of Token (IDL structure) - e.g. HandshakeResultToken - for the final output of the Authentication handshake like this:
   • class_id DDS:Auth:PKI-DH:1.0+Result
   • binary_properties: challenge1, challenge2, SharedSecret

In both cases, it would change the specs of the methods get_shared_secret() and return_shared_handle() of the Authentication plugin, section 9.3.3.