[foaf-protocols] local password - was WebID pre-alpha specification (uses RDFa)

[Henry Story]

On 16 Jul 2010, at 22:39, Bruno Harbulot wrote:

> Hi Henry,
> 
> On 16/07/2010 21:55, Henry Story wrote:
>> 
>> On 16 Jul 2010, at 20:30, Bruno Harbulot wrote:
>> 
>>>> 
>>>> I don't quite grok the public terminal scenario and public key concern,
>>>> so you might need to clarify further. Worst case we get a nice problem
>>>> scenario use case etc..
>>>> 
>>>> You can have many pubkeys per WebID.
>>> 
>>> I'm talking of the problem of using a machine/browser that you haven't
>>> used before and that isn't necessarily yours. For example, you use a
>>> friend's computer to log on to some website.
>> 
>> More and more people will browse the web on their cell phones, if they don't
>> allready do.
> 
> Support for certificates on mobile phones isn't quite as "it just works" 
> yet across all phones. Agreed, this will improve.

Indeed. One of the problems I just heard from a cell phone manufacturer was that
TLS connections on cell phones could take 20 seconds. This problem is no longer.
So expect a lot of growth there.

> 
>> Longer term the solution for people that need to use public
>> terminals -  which by default are insecure anyway - would be to give them USB crypto keys.
> 
> I think you're unrealistic on this one. USB crypto keys (a) are not as 
> cheap as you seem to think, (b) are a pain with respect to drivers 
> (often proprietary, not necessarily installed or installable, definitely 
> for public terminals) and (c) a number of public terminals don't let you 
> anywhere near the USB ports.


I was saying longer term. In any case longer term you probably won't need public terminals. In buisnesses though, for Sun Ray stations for example, it should be completely practical.

> 
> 
>> I don't have the feeling how big the problem is really or if it is on
>> the rise. Nor is it clear how problematic people will really find the
>> WebId solution.  Nor is it said that for those issues people could
>> not use OpenId anyway: A WebID could by default come with an openid
>> too.
> 
> I'm sorry, but certificates are just harder to use. If you log on from a 
> new machine, create a new certificate there, even the log out procedure 
> is harder: either you need to delete your new public key from your WebID 
> provider (probably the easier) or you need to delete your certificate 
> (that requires going into various preference menus). If it's a public 
> terminal, maybe it will just wipe all the preferences, but if it's a 
> friend's machine, deleting your own cert from his/her preferences is the 
> least you can do.

Ok, so that is why we now have OpenId and WebID. Choose what you prefer.

> 
> 
>> Finally it is clear that WebID is more secure than OpenID, as far as authentication goes, due to:
>> 
>>   - the simplification of the protocol
> 
> Simplification made at the expense of having to deal with certificates. 

You are switching theme here. We were speaking security, and now you are speaking user friendliness, which itself could be improved.

> That doesn't improve the security that much, since once again, the 
> weakest link in the chain is still the same (the WebID itself, like the 
> OpenID, is the entry point for whatever information is gathered afterwards).

Yes, it is not at that level that WebID is more secure. It is the fact that we only need one such service. OpenID needs the OpenId provider too - which could be broken into - and the extra verification between the Relyng party and the Identity Provider to verify the cookie. It is quite easy to see the difference in this schema

  http://blogs.sun.com/bblfish/entry/the_openid_sequence_diagram


> OpenID-enabled services that require a trusted OpenID provider may have 
> an advantage there, in fact, because they get the assertion from a 
> trusted party (hence the complication of the protocol).

Nothing in OpenId says its trusted. That is just what people would like to believe.
And any procedure to add such trust can be added to linked data procedures too.

> 
> 
>>   - no possible typing mistakes
> 
> I can type in my e-mail address in Google. I don't even have to know my 
> WebID. That's not really a security issue...

you can make a spelling mistake in typing. That means someone could then capture your password perhaps.

> 
> 
>>   - no password being typed (for public terminals that is an issue)
> 
> You'll somehow have to type a password in your WebID provider's password 
> to be able to re-generate a new certificate in your account (like what 
> you do with XWiki), so you're back to the same problem.

that can be a one time password. Usually you don't need that. 
Btw, I have had this computer for 4 years. Getting a new key every 4 years
would be a great improvement.

> 
> 
>> That is all both specs deal with. Trust is a different issue and
>> neither OpenId nor WebId as we are specifying. WebId clearly makes it
>> easier to specify trust in the web manner.
> 
> Sure, but 3rd parties will have to link to other public keys, which is a 
> problem for certificate generation on-demand.

? Why do 3rd parties need to link to other public keys. Just link to 
the WebId. Or if you need it create a special public key that does not change.

> 
>> You have an idea of using public keys to sign documents to get more
>> distributed security. That is not a problem really. We could create a
>> special public key that people use to identify someone for signing
>> purposes.
> 
> That's not what I'm talking about. I'm talking about things like /me/ 
> putting /your/ public key in my FOAF file (along side foaf:knows) so 
> that I, as a 3rd party to whatever service to want to connect, can 
> assert that it is you indeed with a higher level of assurance.

Ok, so perhaps that will be an issue for another even more secure protocol,
which is also going to be a lot more difficult to implement for all kinds of
reasons. 

Also why not put one long lasting public key of mine in your foaf file.
I could then perhaps use that public key to sign my foaf file, which would
prove that it had not been altered?

Would that satisfy you?


> Putting other people's public keys in our FOAF file is feasible, we just 
> haven't done it (I've actually put your public key in my FOAF file, a 
> while back, but I think an early implementation of our libraries choked 
> on it because of an incorrect SPARQL query at the time, a small early bug).
> (Signing those documents is an even higher level of assurance, but 
> that's to solve the problem of how you trust the way you've obtained the 
> 3rd party's FOAF document.)
> Of course, the 3rd-parties need not be foaf:Persons you know, but you 
> can mix hierarchical and web-of-trust in that model.

yes, I don't think we have excluded those options. But as you see
just getting the basics working is already a lot of work. As Volatair said: The perfect is the enemy of the good.

> 
> As I was saying just above, as soon as 3rd parties start including your 
> public keys and you enhance the security using that, you lose in terms 
> of usability w.r.t. on-demand certificate generation.

Not necessarily, as I managed to show above.

> In short, WebID can provide you additional security when you're using a 
> key others know (typically, on once of your devices), but will not 
> improve the situation for keys your social network don't know (typically 
> on devices that aren't yours, because you'd have generated temporary 
> keys for that device). Nothing wrong with that.

If you create a temporary public key with for some temporary device, and that
foaf file is signed with a long term pub key, then you should be ok. But in the
end, clearly having your server compromised is not going to be good whatever you
do. And that seems to be what you want to solve. OpenId has that same problem 2ce over, since you need to avoid 2 servers being compromised.


> WebID can improve the security of the authentication,

Good to hear you say that! 

> I'm just saying we 
> need to be clear on the reasons. The arguments you put forward are not 
> really security-related.

They are precisely security related.


> Best wishes,
> 
> Bruno.
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols