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

[Bruno Harbulot]

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.

> 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 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.


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


>    - 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...


>    - 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 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.


> 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.
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.

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.

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.
WebID can improve the security of the authentication, I'm just saying we 
need to be clear on the reasons. The arguments you put forward are not 
really security-related.




Best wishes,

Bruno.