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 _______________________________________________ DAS mailing list [email protected] http://lists.open-bio.org/mailman/listinfo/das
