[foaf-protocols] authenticating from a command line tool

[Roger Menday]

Hi Henry,

Thanks for replying. Some comments inline ...
>     Yes, I think your use case makes complete sense.
>>
>>
>> I am following (quietly) all the FOAF+SSL discussions - looks pretty 
>> interesting, and I would like to use it. So, I have a question - I 
>> hope my terminology is not too wrong.
>>
>> One part of my use-case is some kind of command-line tool.
>
> Yep, any kind of user agent is welcome to the party :-)
>
>> When it starts for the very first time, it generates a self-signed 
>> certificate.
>
> yes.
>
> Or it could check to see if the user allready has a pgp key. There is 
> some code in https://sommer.dev.java.net to transform a pgp key into 
> an X509 certificate.
>
>
>> Then the user tells the commandlinetool, what to look at - for some RDF.
>
> ok. RDF or antyhing else btw. :-)
>
>
>> It tries to hit the website the user provides - a SSL+FOAF one. It 
>> tries to authenticate with the certificate. The site doesn't 
>> recognise it. And in the HTTP response codes, it tells the 
>> commandlinetool that.
>
> ok.
>
>> The web site also publishes a short lived resource, such that if the 
>> user then visits it with their browser - and once authenticated (i'm 
>> thinking with openid), they can dynamically add to the authorisation 
>> triples and then allow the commandlinetool access the next time it 
>> tries.
>
> Ok. So here you want to use the OpenId protocol to authenticate the 
> user, and from then on the server would rely on the foaf+ssl 
> connection to do this?
yes. i think so. the user authenticates (somehow - probably using 
openid) and does some interaction
.... which has the result that some some foaf triples are published 
which shows that the commandlinetool is a new friend.
>
> If your server published then a little piece of foaf with the public 
> key then you would have the full foaf
> +ssl protocol.
that I definitely intend to do.
> Which would then allow other services in your organization to trust 
> that client if for example they trust ids your service publishes.
>
yes !! i like

on one side, the other services would still need "talking to" - to tell 
them trust the first one as a reliable source of friendship information 
- which carries the same overhead as the client doing it ... but, once 
that is done *once*, it will be much easier to set-up new clients (with 
new certs) on different workstations.  
> Now your command line client could also learn the openid endpoint of 
> its user and his password, and so your user won't need to go to a web 
> browser to open do the openid rigmarole. There are java libraries for 
> the openid dance for clients I think.
>
going to a web browser is a little bit of an un-natural diversion, i agree.
but, true - openid is a rigmarole for the underlying http agents doing 
the dance, but for the user, it's a pretty smooth experience.

furthermore, AFAIK, an agent doing the openid dance has some 
difficulties ... i think openid is only really intended for when there 
is a human directing it.

actually, it doesn't really have to be openid. it could be foafssl certs 
... i just have openid right now, that's all.
>> I've seen this kind of thing before, in a number of places.
>> I wonder what the loopholes are ?
>
> The interesting piece here may be to generalize this. What is needed 
> would be for your https enabled server to tell someone that they need 
> to log in to an openid endpoint. If this can be done in RDF, which 
> should be easy, then any client that failed to access the 
> https://enpoint could be told how they need to authenticate themselves.
In my case, maybe there isn't a stage 1 (of 
http://blogs.sun.com/bblfish/entry/foaf_ssl_creating_a_global). i.e. 
there isn't a publically accessible resource telling me how to get to 
the private one ... it's all private from the outset ... (?)

Or, maybe I should just put a public resource as well .... ?

Otherwise, I was thinking a 401 (Unauthorised), and then some redirect 
to openid endpoint to authenticate (if not already), and then some HTML 
form, which 1. shows the user the certificate from the agent attempting 
to gain access, and 2. some form to allow the update the authorisation 
(if the user recognises the cert) - essentially, hypermedia.

I don't know much about 401 (i know what 
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2 tells 
me), but i suppose that some part of the header could indicate that 
ssl+foaf is needed ... and this could be defined somehow (???)

Thanks again,

regards,

Roger

> I think it would be useful to explore this at some point if people 
> feel the need.
>
>     Henry
>
>> Thanks for any comments.




-------------------------------------------------------------------
-------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich

Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDir'in Bärbel Brumme-Bothe
Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt,
Dr. Sebastian M. Schmidt
-------------------------------------------------------------------
-------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: r_menday.vcf
Type: text/x-vcard
Size: 153 bytes
Desc: not available
Url : http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20081208/27f9f41a/attachment.vcf