Hi all,
Following Thursday's teleconference, I've attached some pros and cons of
adopting OpenID as an authentication scheme for DAS.
Note I have said nothing about what servers and clients should do
following authentication (e.g. how to indicate to clients that data
content is dependent on authentication) - whilst important, IMO this
issue is independent of authentication scheme.
Cheers,
Andy
Pros of using OpenID:
1. Single-sign-on is convenient for the user - the concept of "signing into
DAS" (or just the client) as opposed to signing into each DAS server
separately. Ensembl users are already commonly confused as to where data is
coming from; requiring them to log in to a DAS server makes this worse as they
need to know about how the client works to be able to use it.
2. No delegation of trust - other systems require users to "trust" clients with
their login details (username/password). Relevant for web-based clients such as
Ensembl, and a deal-breaker for highly sensitive data such as GWAS or even
pharma.
3. Simpler authentication relay for the client software - need only delegate
the ID to the DAS server rather than collect all information from the user.
4. Provenance and attribution - particularly useful for community annotation,
it would be possible to identify individuals:
a) reliably
b) without publishing sensitive information
c) between servers (can track annotations and their changes across the whole
network)
5. Client libraries for several languages - C#, C++, Java, Perl, PHP, Python,
Ruby, Coldfusion, Apache, Smalltalk
http://wiki.openid.net/Libraries
6. DAS registry already uses it, as does MyDasty (configurable version of
Dasty) and in-progress implementation of writeback for Dasty. Thus precedent
for DAS.
Cons of using OpenID:
1. Unfamiliar login experience for users - not a username or email buy an URL.
Also, users are redirected to a separate site to complete login process.
2. Is still more complicated to implement than HTTP.
3. More difficult for businesses/organisations to integrate with existing
internal login systems than user/password schemes (either link internal
accounts to OpenIDs, or become an OpenID provider).
4. Accidental loss of anonymity - potential for all DAS servers knowing who is
browsing them. Can prevent this, but lose some of the "seamless" benefit.
5. Possibility of phishing via impersonating OpenID provider. Though this is
actually easier with other schemes by impersonating DAS servers themselves.
_______________________________________________
DAS mailing list
[email protected]
http://lists.open-bio.org/mailman/listinfo/das
