Hi
I'd be against using OAuth because it will probably suffer from the
same limitations that OpenId suffered from. 1) It will be the in thing
for a while with support for certain programming languages or
environments (such as browsers) but will soon go out of fashion when
something else with a cool sounding name comes along :)
2) It takes us away even more than we already are from the principle
that the DAS system should be simple.
3) If it's complicated it can be difficult to change your application
if the environment that you are running your application in changes or
other factors make you change it (e.g. when the sanger web site no
longer supported sticky sessions I had to try and rewrite the openID
code for the registry which turned out to be dependent on normal in
memory Java sessions, so I had to change code that I didn't really
understand, thus introducing security holes, so I ended up turning to
good old username and passwords).
4) Everybody understands username and passwords boxes in an user
interface whereas if we start going on about OAuth authentication and
using their facebook accounts people will get frightened off - I'm
also not sure I won't my gmail or facebook accounts to log me in to
the DAS registry automatically and start distributing my contact
lists ;)
My preference and I think most other peoples when we have been on this
discussion before (3rd time around??) is to use basic https security
that has been around for years. I also prefer the option of sending
the username and passwords for every request for a secure data source
as the server then remains in one state (the registry sends them in
the headers, MyDAS currently sends them in the xml - we need to
decide which to use). This would be in preference to an amazon S3 type
system where tokens are given for a limited period of time to the
client/user (the S3 type system would be my second option). These
would be a good balance between ease of development/understanding and
security. If specific clients and servers wanted to add extra security
they could add IP restrictions so they know the client is hosted at a
specific place.
Cheers
Jonathan.
On 16 Jan 2012, at 23:16, Dan Bolser wrote:
Heh... it doesn't work:
https://github.com/dbolser/TwitterBot---nowlistening-Perl-script-for-xmms
Not sure what I'm doing wrong.
On 16 January 2012 21:12, Dan Bolser <[email protected]> wrote:
On 16 January 2012 18:31, Andy Jenkinson <[email protected]>
wrote:
I rather suspect this is a purely mental exercise, but that's fine
for me ;)
<snip (too mental for me ;-)>
OAuth is entirely based upon the notion that the server with the
data (e.g. Google Contacts) can trust the application (e.g. the
Android Contacts app) to do the right thing with the data. There
is no requirement that the person who owns the data, or any other
person, has to be present, and the application doesn't have to
prove that this will happen. It just has to get the user to agree
that the application can be trusted. It's up to us therefore to
provide a secure link between OpenID and OAuth.
Right, the person who 'owns' the data (i.e. a list of contacts hosted
on a Google account) explicitly grants the third party 'app'
permission to access the data (via the account) in a specified way
(as
defined by the Google APIs). That app can then email all your
contacts
in the middle of the night while you're sleeping, but you trust that
that won't happen when you click the 'grant' button.
i.e. I (the verified me) can grant Ensembl permission to access my
SNP
genotype data from 23andMe (hah), and I trust Ensemble not to do
anything nasty with that data when I log off.
Although it's a bit of a pain to set this up, the point is that
literally thousands of app developers (including me) have done it
before, and there are hundreds of docs. Here is where I started
when I
built a command line twitter bot:
https://dev.twitter.com/docs/auth
I'm not trying to say its quick and easy to do and everyone should do
it like this, I just thought I'd provide the above encapsulation,
which hopefully isn't too far from how it could be done.
Cheers,
Dan.
_______________________________________________
DAS mailing list
[email protected]
http://lists.open-bio.org/mailman/listinfo/das
Jonathan Warren
Senior Developer and DAS coordinator
blog: http://biodasman.wordpress.com/
[email protected]
Ext: 2314
Telephone: 01223 492314
--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
_______________________________________________
DAS mailing list
[email protected]
http://lists.open-bio.org/mailman/listinfo/das
