[DAS2] authentication: don't bake anything into the spec

[Gregg Helt]

As part of our review of different authentication mechanisms to integrate
into the DAS specification(s), I volunteered to summarize the pros and cons
of the null hypothesis.  That is, not "blessing" any particular
authentication strategy in the DAS protocol itself, but rather leaving
authentication to be determined by the server and client implementations
that need it.

To avoid too many double negatives, I'll flip that around and discuss pros
and cons of having any authentication embedded in the spec.

Cons of having authentication strategy embedded in the DAS protocol:

1) Increases spec complexity.

2) If it's required, then increases development overhead for client and
server implementations that don't need it or need to use an alternative
strategy.

3) May negatively impact adoption by some organizations.  Blessing a
particular authentication strategy, even if alternatives are allowed, can
have a dampening effect on adoption by organizations that need to use an
alternative strategy.  In other words, the protocol may be viewed as being
optimized for the blessed strategy at the expense of others, increasing the
chances of a more agnostic alternative being adopted instead.  Even if the
bioinformatics folks at an organization want to use DAS, in many
organizations (at least the corporate ones) they have little influence on
security-related technology decisions.

Pros of having authentication embedded in the DAS protocol:

1) More likely that client and server implementations can be used "off the
shelf" as long as the authentication needed is met by the blessed strategy

2) By virtue of (1), may positively impact adoption by some organizations

3) Promotes uniformity across various implementations