[foaf-protocols] FOAF+SSL delegation: logging in to an HTTP server

[Bruno Harbulot]

Hi Kingsley,

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 
needs).
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 
> value.

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 
> bootstrap.
> 
> 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 
latest message):
> 
> 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.


Best wishes,

Bruno.