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

[Reto Bachmann-Gmür]

Just a little addition to Bruno's remarks:

- It would be against the open world principles to think a certificate
could be invalidated by removing it from the profile, the temporary
certificate should have a limited lifetime from beginning

- The easiest way to support access from public terminal both for
sites (who don't need to provide additional OpenId support) and for
users (who don't need to install a certificate) is to use a foaf+ssl
proxy to which you log in with a (one-time) password


Cheers,
reto

On Fri, Jul 16, 2010 at 11:39 PM, Bruno Harbulot
<Bruno.Harbulot at manchester.ac.uk> 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.
>
>> 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.
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>