At a minimum the AmqpCredentialType enumeration will grow and there
will be new signatures on the AmqpCredential.
If other changes are required, for consistency, the
AmqpTransportSecurity structure and its support classes should try to
look like existing WCF bindings that support these or similar
mechanisms. The existing design follows that principle.
As an analogy take a look at HttpTransportSecurity and
HttpClientCredentialType for an existing Microsoft binding that
handles a wide range of authentication and security options.
The base WCF ClientCredentials class can already handle most simple
certificate and username/password cases and is meant to be extended to
handle special cases and arbitrary security tokens. It's flexible,
but not necessarily easy to handle arbitrary proxy and firewall
situations. Users may prefer to use an AmqpCredential in many cases.
The AmqpCredential provides a mechanism to separate broker credentials
from WCF service endpoint credentials and also provides the building
blocks for more complex bindings in the future (e.g. failover between