Re: Sketch of a very simple identification protocol

Hi Henrik,

thanks a lot for the reply. I posted a link to it in a comment to the
RDFAuth post.

On 1 Apr 2008, at 23:33, Henrik Nordstrom wrote:
>
> tis 2008-04-01 klockan 17:47 +0200 skrev Story Henry:
>
>> http://blogs.sun.com/bblfish/entry/rdfauth_sketch_of_a_buzzword
>>
>> It is very simple, and probably could be further simplified. Some
>> people have noted the similarity with HTTPS, and how this could be
>> thought of as an extension to that perhaps [2].
>
> I see more similaries with HTTP Digest authentication than HTTPS..

Yes. That is what I based the idea on. One way it starts rejoining  
HTTPS is that the server could use the public key to encrypt the reply  
so that only the client can read it. It is an interesting thought,  
though I have been warned that encryption with asymmetric keys is  
costly.

There is another way to relate it directly to HTTPS developed by Toby  
Inkster, in an email I refer to below.

> Actually you would solve some of the problems mentioned like replay
> attacks and nonce management if you do things the Digest way with  
> server
> nonce, client nonce + server nonce reuse counter.

sounds right.

> You cannot shortcut 1+2 unfortunately while keeping RESTful as HTTP  
> does
> not allow mixing public and authenticated content on the same URI, and
> attempting to do so will mess up the cache model of HTTP. But 1 only
> needs to be performed once for the whole duration of the session  
> (which
> can be arbitrary long, subject to server controlled constraints).

Ok. That is really helpful to know that public and authenticated  
content cannot be served from the same URL.

> But I feel this proposal is perhaps trying to layer too much at the  
> same
> time. Better to separate identification from authentiation. If you use
> pgp for authentication then the identification key in the  
> authentication
> should be the pgp identity (which is a pgp key with some name & email
> recorded). But it's also worth noting that pgp signatures do embed the
> needed information to identify which key has made the signature (but  
> not
> it's distribution points).


Yes. I completely agree. There is no need to reduce the message load  
from the client to the server. It may as well have the following  
headers:

1. A header for the ID, which would be an IRI
    so this could allow ldap IRIs, and other protocols in addition to  
HTTP
    (but I favor HTTP).
    By using some naming service the server can the get information  
about entity named by that IRI

     User-Id: http://bblfish.net/people/card#me

2. A header for the public key and the type of the key

     User-Public-Key: Type=OpenPG,uri=http://bblfish.net/people/henry/henry.pubkey.asc


3. An encoded string that proves that the User Agent knows the private  
key.

Then there just needs to be a way to tie the public key to the User- 
Id. The simple way is to have the User-Id representation point to the  
public key, which proves that he who has write access to the UserId  
resource endorses the public key.

(this is the OpenId trick)

> What this means is supply the foaf identification separately in an
> informal header if needed. It also makes it trivial to use other forms
> of authentication with no change in the semantic identification. One
> example of such alternative authentication would be SSL.

yes, Toby Inkster suggested that the foaf file (or the ldap server)  
could also point to a unique identifying property of the client's SSL  
public key (its hex_id) in

http://lists.w3.org/Archives/Public/semantic-web/2008Mar/0207.html

this would allow an SSL connection using that key to count as client
authentication

> So there is three components
>
> * Identification. "This is who I claim to be"
>
> * Authentication. "This is how I prove the above to be true"
> * Authorizatioon. "I know you, access granted"
>
> I would make the identification separate, and use authentication to
> prove the identification when needed.

Yes.

I wonder how I should proceed from here...

> In the end this boils down to the web of trust of the authentication
> scheme used.
>
> Another related alternative using OpenPGP for http authentication  
> would
> be to use enigform for the requests requiring authentication. Layered
> slightly differently, not following the HTTP authentication scheme  
> model
> in header names, but conceptually is one..
>
> http://www.buanzo.com.ar/sec/enigform.en.html

Very interesting. I'd love to hear Arturo's feedback.
What foaf provides is I think a way to create a more flexible web of  
trust. Perhaps not quite as trustworthy as key signing parties, but  
easier to undo.
I can have my foaf file link to a signature of your key. If I loose  
trust in it, I could remove the link... I think the two compliment  
each other nicely.

Henry

>
>
> Regards
> Henrik
>