[foaf-protocols] FOAF+SSL delegation: logging in to an HTTP server
Bruno.Harbulot at manchester.ac.uk
Tue Apr 28 16:34:20 CEST 2009
Kingsley Idehen wrote:
> Bruno Harbulot wrote:
> Business make decisions on a: cost vs benefit analysis basis, solely.
(I'm not disputing your analysis.)
>> If you consider something like the UK Access Management Federation
>> for Education and Research <http://www.ukfederation.org.uk/> (not
>> quite enterprise, but close enough), which is currently using
>> Shibboleth but where I think FOAF+SSL could be valuable, doing this
>> takes years or planning and implementation.
> Simply not a good example, quoting you re.: "not quite enterprise....".
Well, I meant "not quite enterprise" in the sense that it's across
academic institutions rather than private companies. Nevertheless, the
motivation is to have a common ID across these institutions and the
scale is certainly that of a large company.
A company might not take years to change the authentication mechanism to
its systems, but I don't think these decisions are taken lightly.
The cost vs. benefit analysis is not an easy process (it's not meant to
be), especially because security is involved.
The cost of enabling SSL in a server is indeed negligible compared with
the potential benefits, but we do have to show those benefits (and I
reckoned that it would be easier by having some existing website as
examples, most of which may not be able to have SSL in the way FOAF+SSL
As I've said, I doubt the dereferencing way of doing verification is
acceptable enough for enterprise-grade security. There's still more work
to do on this side.
(The other problem being from the user point of view: handling of
private keys is likely to be a burden. The benefits are to be
demonstrated to the users too, and suitable training has to be provided.)
>> The personal and small companies websites are where FOAF+SSL can gain
>> visibility, because people are often willing to experiment more
>> easily. However, my point was that SSL isn't necessarily commonly used
>> there. (I think Melvin understands what I'm saying in his reply to
>> this message.)
> This is not about company websites solely, its about enterprise networks
> which also include intranet and extranet scenarios. In short its about
> enterprise points of presence on HTTP networks. How granular policy
> based security is applied therein, that's the focal point of FOAF+SSL
Yes, indeed. In addition, FOAF+SSL may be use with other SSL-based
protocols (e.g. IMAPS), although the application would have to process
the resulting Web ID.
> A specification is nice, but I don't think that's the key to success
> here. Look at the Web, did Web specs come before or after point of
> critical mass? The specs started being refined after the successful
> History is a great teacher.
Agreed. My original point was that we shouldn't consider this delegated
authentication mechanism as a temporary solution, because I thought it
would be one of the things that people would find useful in the short
term, and that would thus be likely to stick around for a while (for
systems that don't need more).
I did start by providing implementations (SAML-based and custom) in Java
(yet to be modified with the renaming of parameters, as discussed). My
point about the spec is for us to work towards the same goal across
different languages. I think it makes more sense to work towards
libraries that can talk to each other.
I think the my disagreement with Henry is on this point (quoted from his
> Furthermore these services have very very little interoperability requirements. Every such "IdP" could create its own protocol to help services that do not have SSL help to find a user's WebID, and there would be absolutely no problem. Even the switching costs of a service from one such service to another would be minimal. As a proof foaf.me switched to using the foafssl.org service provider in less than 3 minutes, a few weeks ago.
We might as well work towards a common way of doing this, something that
works between Java/PHP/Perl... I've done a Java version, published under
BSD licence (so there should be a low barrier for adoption), I'm not
planning to implement it in other languages. Because the SP and the IdP
don't have to be implemented in the same language, it would make sense
for having some interoperability there. For that reason, I think it
would be a waste of time for each IdP to create its own protocol.
More information about the foaf-protocols