Subject: Re: Sketch of a very simple identification protocol

From: Lisa Dusseault <[email-masked]>
Date: Tue, 1 Apr 2008 13:38:42 -0700

Another idea in the ether these days is much the same thing, but with  
a different focus and nomenclature: it's typically described as doing  
service discovery in a way that doesn't require DNS changes.

How do I as a person, advertise my personal blog, my calendar, my work  
blog at all, let alone as them being related to me?   My calendar is  
probably hosted by my company or at Google, my personal blog at  
LiveJournal, my work blog by some IT team at my company that has  
nothing to do with the email/calendar team.  There's no way I can get  
those service providers to work together or do something that's  
specific to me.  The extensive work on S-NAPTR and DDDS isn't going to  
help because my company won't put a DNS record saying "Lisa's calendar  
is on google under this address".  Nor will anybody else except me.

But since I don't run a DNS server and don't pay GoDaddy to run one  
for me, I'd rather the information about these related resources be in  
an HTTP resource somewhere -- that's a technology I do have access  
to.  We do have a bootstrap problem, but to a certain extent that can  
be solved with well-known naming conventions.  Just like spiders  
recognize "robots.txt" today, there's a good chance that robots or  
other automated agents can recognize a well-known file name for  
information that advertises services.

Lisa

On Apr 1, 2008, at 8:47 AM, Story Henry wrote:

> By thinking about a use case involving Distributed Open Social  
> Networks we found the need for a light weight identification system  
> such as OpenId, but without the many redirects and better able to  
> work with REST web architecture and Linked Data. The main reasons  
> for needing such a protocol were laid out on the Semantic Web  
> mailing list [1].
>
> I summarized and illustrated a sketch of such a protocol on a recent  
> blog post.
>
> 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]. In any case I  
> thought that with some protocols experts on this list would be able  
> to fill in the gaps, suggest improvements or point to specs that  
> already do what is needed.
>
> Yours sincerely,
>
> 	Henry
>
>
> [1] http://www.w3.org/mid/[email-masked]
> [2] see http://www.w3.org/mid/[email-masked]
>

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 01 Apr 2008 23:33:31 +0200

tis 2008-04-01 klockan 17:47 +0200 skrev Story Henry:

> thought of as an extension to that perhaps [2].

I see more similaries with HTTP Digest authentication than HTTPS..

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.

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

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

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.

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.

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

Regards
Henrik

---

From: Story Henry <[email-masked]>
Date: Wed, 2 Apr 2008 10:31:32 +0200

Hi Lisa!

With a calendar vocabulary, it should be easy to add a relation to  
foaf, find an existing one, or create one that in N3/Turtle would look  
like this:

@prefix : <http://lisa.org/ont/cal#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

:calendar a owl:ObjectProperty;
     rdfs:label "calendar location";
     rdfs:domain foaf:Agent;
     rdfs:range :Calendar;
     rdfs:comment "relates an agent to its calendar".

:Calendar a owl:Class;
     rdfs:subClassOf foaf:Document;
     rdfs:label "a Calendar";
     rdfs:comment """a calendar document. Should be able to return one  
of a number of calendar representations""" .

It would then be easy to add to your foaf file the link to your  
calendar. In N3 again you could have the following in your foaf file

@prefix cal: <http://lisa.org/ont/cal#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix lisa: <http://lisa.org/#> .

lisa:me a foaf:Person;
     foaf:name "Lisa Dusseault";
     foaf:homepage <http://lisa.org/> ;
     foaf:blog <http://nih.blogspot.com/> ;
     cal:calendar <http://lisa.org/cal/>;
     foaf:knows [ = <http://bblfish.net/people/henry/card#me>;
                  foaf:name "Henry Story" ].

( With RDFa [2] this could also be embedded as html in your home page. )

I am missing out the link to your GPG key and the other fun stuff that  
you could link to in there. In order to avoid making the file too big  
it may be useful as on a web page to cut some of it up of course, and  
cross link between them. In any case it is then easy to publish the  
foaf file, in a RESTful manner as I did [1], and you have a foaf name  
that can return representations of where your calendar is.

Now I can imagine that with a protocol such as the sketched RDFAuth  
you could allow access to a full view of your calendar only to people  
you know or to the people who know people you know, or to the people  
who are part of a certain organization, as specified by that org. It  
is up to you. All you need to know is their unique id [3]: and why not  
have a URL as ID. As you point out, we all have easy access to the web.

Henry

PS. You may also be interested in the SIOC (Semantically Interlinked  
Online Communities) vocabulary. http://sioc-project.org/

[1] http://blogs.sun.com/bblfish/entry/i_have_a_foaf_file
[2] http://www.w3.org/TR/xhtml-rdfa-primer/
[3] The fun thing is that this also makes drag and drop across  
applications and computers really easy. see: http://blogs.sun.com/bblfish/entry/universal_drag_and_drop

On 1 Apr 2008, at 22:38, Lisa Dusseault wrote:
> Another idea in the ether these days is much the same thing, but  
> with a different focus and nomenclature: it's typically described as  
> doing service discovery in a way that doesn't require DNS changes.
>
> How do I as a person, advertise my personal blog, my calendar, my  
> work blog at all, let alone as them being related to me?   My  
> calendar is probably hosted by my company or at Google, my personal  
> blog at LiveJournal, my work blog by some IT team at my company that  
> has nothing to do with the email/calendar team.  There's no way I  
> can get those service providers to work together or do something  
> that's specific to me.  The extensive work on S-NAPTR and DDDS isn't  
> going to help because my company won't put a DNS record saying  
> "Lisa's calendar is on google under this address".  Nor will anybody  
> else except me.
>
> for me, I'd rather the information about these related resources be  
> in an HTTP resource somewhere -- that's a technology I do have  
> access to.  We do have a bootstrap problem, but to a certain extent  
> that can be solved with well-known naming conventions.  Just like  
> spiders recognize "robots.txt" today, there's a good chance that  
> robots or other automated agents can recognize a well-known file  
> name for information that advertises services.
>
> Lisa
>
>> I summarized and illustrated a sketch of such a protocol on a  
>> recent blog post.
>>

---

From: Story Henry <[email-masked]>
Date: Wed, 2 Apr 2008 10:59:16 +0200

Well, I just noticed that the rdfa spec I mentioned in my previous  
email points to a calendar vocabulary. http://www.w3.org/TR/rdfcal/

My point below was to show how simple it is to create a vocabulary  
with HTTP URIs. So by using exactly the same trick as the one foaf  
uses to give HTTP URIs to people, below we gave some other HTTP URIs  
to a relation and to an abstract class.

The beauty, as with the web, comes of course when someone puts a  
representation at that URI that describes the URI. This makes it of  
course a lot more likely that others will use that name.

Henry

PS. Sorry if this is all known to you. I am just not sure how far this  
community has been following the work from the semantic web and linked  
data community.

---

From: Story Henry <[email-masked]>
Date: Wed, 2 Apr 2008 14:16:24 +0200

Hi Henrik,

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

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

> nonce, client nonce + server nonce reuse counter.

sounds right.

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

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

> 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

> prove the identification when needed.

Yes.

I wonder how I should proceed from here...

> 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

---

From: Arturo 'Buanzo' Busleiman <[email-masked]>
Date: Wed, 02 Apr 2008 12:24:08 -0300

Lisa Dusseault wrote:
| But since I don't run a DNS server and don't pay GoDaddy to run one for
| me, I'd rather the information about these related resources be in an
| HTTP resource somewhere -- that's a technology I do have access to.

Sounds like a very simple, yet concrete and useful, approach.

| We do have a bootstrap problem, but to a certain extent that can be solved
| with well-known naming conventions.  Just like spiders recognize
| "robots.txt" today, there's a good chance that robots or other automated
| agents can recognize a well-known file name for information that
| advertises services.

I'd use a very simply formatted XML file... like...

<person name='lisa' sex='female' location='California, USA' blah='blah'>
	<category type='personal'>
		<item type='blog' title='Lisa&amp;s Blog' url='http://lisa.blogspot.com' />
		<item type='album' title='Lisa&amp;s Pictures' url='http://pictures.com/lisa' />
	</category>
	<category type='professional'>
		<item blahblah />
		<item blahblah />
	</category>
	<category type='academic'>
		<item blahblah />
		<item blahblah />
	</category>
</person>

Then the browser could query for this file and show an icon to display 'identification info for the
host' or something...

- --
Arturo "Buanzo" Busleiman
Reliable inter-continental Mail Relay Service - Ask me!
Independent Security Consultant - SANS - OISSG
http://www.buanzo.com.ar/pro/

---

From: Arturo 'Buanzo' Busleiman <[email-masked]>
Date: Wed, 02 Apr 2008 13:10:40 -0300

Story Henry wrote:
| PS. Sorry if this is all known to you. I am just not sure how far this
| community has been following the work from the semantic web and linked
| data community.

It's all new to me. I'm quite ashamed of my previous email (XML) :P

- --

---

From: Arturo 'Buanzo' Busleiman <[email-masked]>
Date: Wed, 02 Apr 2008 14:48:57 +0000

Story Henry wrote:
| Very interesting. I'd love to hear Arturo's feedback.

Hi Everybody, thanks for drawing me into this conversation. You can call me Buanzo. That URL is not
really well maintained, so I'll provide better ones at the end of this message.

Enigform is a Mozilla Firefox extension that provides the ability of signing requests. Actually,
signing certain elements of the request (some headers, and the GET query string or POST payload).
The signature and other elements such as Enigform version and GnuPG Version are appended to the request.

mod_openpgp is the Apache module that provides the necessary server-side element. It gets signed
requests, verifies them, and adds headers with the useful information which can then be used by PHP,
etc. It can also import a public key sent via Enigform through an HTTP request but I might remove
that functionality or make it a server-side option.

But the most interesting feature is actually the Session Initiation Protocol. In short:

1) Browser sends a pgp-signed "begin session" request
2) Server verifies it, then generates (and stores) a hash which is sent (in encrypted form using PGP
to the Client's public key) to the Browser.
3) Browser receives that hash, decrypts it. From then on, this session hash will be appended to
every outgoing request to the server. The session hash is included as one of input elements for the
pgp signature embedded in every request.
4) Server can verify if any subsequent request has a valid session hash. Of course, the session is
only verified if the request has a valid signature which includes it. Extra headers are added for
PHP, etc to use as application credentials.

So, basicly, if I hit "Login", I get logged-in without pain and quite securely.

Now, for those URLs:

http://enigform.mozdev.org  - Main Enigform site (firefox plugin)
http://freshmeat.net/articles/view/2599/ (an old freshmeat article I wrote in the early days)
http://www.freesoftwaremagazine.com/blogs/interview_with_arturo_busleiman (interview with some
ideas, like how to use this for internet banking)
http://en.wikipedia.org/wiki/Enigform
http://en.wikipedia.org/wiki/Mod_auth_openpgp (next stable release will get the name changed to
mod_openpgp).

I think I should subscribe

- --