Subject: [keyassure] WebID at W3C and keyassure

From: Henry Story <[email-masked]>
Date: Wed, 9 Feb 2011 18:37:52 +0100

Hi,

	The W3C has started the WebID incubator group http://tinyurl.com/webidxg which is continuing work previously known as foaf+ssl in a more formal setting. I bring this to your attention because the foaf+ssl protocol [1], is conceptually very similar to what I believe keyassure is setting out to do. (I have not seen a draft spec yet, and am going from the group description).

   Where keyassure is attempting to identify a server using uniquely identifying information in the DNS, WebID is identifying an end user (human, robot or agency), via a profile document containing cryptographically uniquely identifying information placed in the web. Keyassure coul probably use the dns typed subject alternative name to identify the verify X509 certifactes, WebID uses the SAN (and IAN) with https IDs to identify the agent. We are both using canonical referential lookups to get the meaning of a name (Domain Name with keyassure, HTTP+TLS with WebID) which we can then use to prove referential integrity (authentication).

   So this parallel would by itself be enough to bring this to your attention. But it turns out that WebID could become all the easier to deploy and use if keyassure works, since TLS on the server will become much easier to deploy. Furthermore it makes some very interesting things possible, as discussed for example in "Turning every Web Server into a CA", 

http://lists.w3.org/Archives/Public/public-xg-webid/2011Feb/0060.html

For this use case, I think it would help there if the full public key were in the DNS. 

WebID is really about enabling a distributed secure social web. [3]

In any case I think it would be very useful to make sure we track each other's work. I am subscribed to this mailing list now, and our conversations are fully public too. Joining the mailing list is easy http://lists.w3.org/Archives/Public/public-xg-webid/ 
and we welcome contributions. It is quite easy to join the XG also, if you feel a desire to participate more actively. :-)

Henry Story

[1]   in development here
    http://www.w3.org/2005/Incubator/webid/spec/
[2] "How does Secure Authentication Work in FOAF+SSL" has an illustration that helps see the parallel. http://www.w3.org/wiki/Foaf%2Bssl/FAQ#How_does_Secure_Authentication_Work_with_FOAF.2BSSL.3F
[3] see the videos posted on my home page:

Social Web Architect
http://bblfish.net/

---

From: Henry Story <[email-masked]>
Date: Thu, 10 Feb 2011 23:41:33 +0100

John Gilmore rightly pointed out that I was not clear in my mail to the list, so I answered his questions in more detail below.

On 10 Feb 2011, at 21:17, John Gilmore wrote:

>> Where keyassure is attempting to identify a server using uniquely
>> identifying information in the DNS, WebID is identifying an end
>> user (human, robot or agency), via a profile document containing
>> cryptographically uniquely identifying information placed in the
>> web.
> 
> I understand this.
> 
>> Keyassure coul probably use the dns typed subject
>> alternative name to identify the verify X509 certifactes, WebID
>> uses the SAN (and IAN) with https IDs to identify the agent. We
>> are both using canonical referential lookups to get the meaning
>> of a name (Domain Name with keyassure, HTTP+TLS with WebID) which
>> we can then use to prove referential integrity (authentication).
> 
> This is so much gobbledygook to me.  Can you explain in English?

Ok, sorry I did type that a bit too quickly yesterday, and it would have done with a  bit more editing before pressing the send button. Let me just rewrite this with spelling mistakes fixed and in less terse style.

Also here is a quick UML Sequence diagram for how this works
     http://www.w3.org/wiki/Foaf%2Bssl#How_does_it_work.3F

So let me try again:

Keyassure will probably use the DNS-ID typed subject alternative name (SAN) or Issuer Alternative Name (IAN) in a *server* X509 certifactes to identify the server as suggested is good practice by 
http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14#section-2.3

WebID uses the SAN (and IAN) with https IDs to identify the agent of a *client* certificate.

We are both using canonical referential lookups to get the meaning of a name. In the  case of keyassure the name is a domain name. The canonical way to look up the meaning of a domain name is to look in the DNS. The canoncial way to look up the meaning of an ftp:// URL (think of a URL as a name) is to use the ftp protocol. So the canoncial way to look up an http or https URL is to use HTTP+TLS, which is what WebID does.

So if I understand correctly, in the future a browser will be able to verify from DNSSEC that a self signed server certificate is indeed able to authenticate the server.

> 
> I see zero point in working on this WebID thing if the actual goal is
> to actually identify me on the web.

You should of course have a choice to authenticate or be anonymous. Web Browsers should show you with what identity you have authenticated and allow you to logout in one click. If we can get together on issues like this to put some pressure on browser vendors, I'd be happy to help. I know of a few security holes that really need some external pressure.

>  I don't want the vast majority of web sites to be able to identify me on the web -- and I think this goal is shared by a large, possibly majority, fraction of web users.

Yes, you should be anonymous by default. 

> To the extent that "WebID" becomes standard, if it makes it easier for
> websites to demand that people "identify themselves" before
> "publishing" information (publishing = distributing "to the public",
> not to individual identified people), then it will be destructive of
> the kind of Web that I want to continue to exist.  I want ordinary
> un-identified people and browsers to continue to have broad access to
> everything published on the web.  I refuse to use sites like the New
> York Times that demand that I login "to a free account" merely so they
> can track what I'm reading.

It is going to be very easy to create a WebID: one click of a button. And you can have as many as you want, on as many sites as you want. It should be easy to create throw away webids too. There is no need to go to any government agency, no need to prove anything. WebIDs are built to enable a web of trust. But you don't need to participate in a web of trust, and if you do, you don't need to reveal it to anyone else than those you trust.

> To the extent that "WebID" makes it harder for people to use a
> different pseudonym with each current website that "demands"
> identifying information, it will be destructive.

WebID allows you to authenticate on sites in a very decentralised way. You can have any number of IDs and place them wherever you want. So it is not restrictive. 

> To the extent that "WebID" makes it impossible for sites like
> bugmenot.com or mailinator.com to exist and function well, it will be
> destructive.

They could provide temporal WebIDs as an additional service, without problem.

> 
> To the extent that "WebID" works like "OpenID", it will never catch on
> anyway.

The extent to which it is different to OpenID is detailed here
http://www.w3.org/wiki/Foaf%2Bssl/FAQ#OpenID_failed.2C_do_people_really_want_distributed_identity.3F

From the user perspective it is a lot easier to use.

>  I use OpenID with exactly one site, because they demand it and
> offer no alternative.  And it's incredibly cumbersome, harder than just
> logging in like other sites require.

Yes, WebID is point and click. No typing. See the short video I put together here
http://bblfish.net/

> 
> Now if somebody at W3C actually automated bugmenot.com in a new
> protocol, so that ordinary people could just set their web browser to
> pretend to be randomly generated other people on sites that demand
> their identities, I'd be much more interested in it.  

It would be very easy to do. You can get yourself a WebID at 
http://foaf.me/ in a few clicks. The UI should definitively be improved. 

> But after
> a brief look at:
> that doesn't seem at all to be what's happening.  Instead it's more
> totalitarian bullshit wrapped in X.509 encoding.

It's certainly not. (Perhaps it's a good thing that it looks like that, ...)

Anyway, what in particular makes you think that in the wording or presentation? We are working on the spec. 

Btw. has this group got a draft spec I could look at?

Henry Story

> 	John Gilmore

Social Web Architect
http://bblfish.net/

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 10 Feb 2011 16:48:42 -0800

On 2/10/11 2:41 PM, Henry Story wrote:
> Keyassure will probably use the DNS-ID typed subject alternative name
> (SAN) or Issuer Alternative Name (IAN) in a *server* X509 certifactes
> to identify the server as suggested is good practice by

In
your earlier message, you said:

> (I have not seen a draft spec yet, and am going from the group
> description).

Please do read the draft. What you say here, which predicates the rest
of your message about similarities with the WebID work, is not at all
correct.

This is not to say that what WebID is doing can't work with the DANE 
effort, just that we are doing completely different things. DANE is 
about getting a temporary trust anchor for a particular 
port/transport/domainname triple for a server, whereas WebID is about 
identifying clients through an HTTPS lookup. There has been discussion 
of using DANE to get a temporary trust anchor for S/MIME clients, and 
that might be extended to doing so for TLS clients, but it would be done 
using the DNS protocol.

---

From: Henry Story <[email-masked]>
Date: Fri, 11 Feb 2011 13:19:43 +0100

On 11 Feb 2011, at 01:48, Paul Hoffman wrote:

> In your earlier message, you said:
> 

Yes, I just read the draft dane 4 
http://tools.ietf.org/html/draft-ietf-dane-protocol-04

I don't think I was far off, but still perhaps too cryptic. In section 2.2 it states that there are four types of things that can be published in the TLSA record

 1 -- Hash of an end-entity certificate
 2 -- Full end-entity certificate in DER encoding
 3 -- Hash of an certification authority's certificate
 4 -- Full certification authority's certificate in DER encoding

So if in 2 the certificate is a DER encoded X509 cert, then if it is a server certificate it should contain according to draft-saintandre the Domain Name in the SAN field. There are a few different types of SAN fields: DNS-ID, SRV-ID and URI-ID. SRV-ID which is defined by rfc4985 is a lot closer to what you are specifying in the RDATA format. (Though it looks like that RFC could be improved to allow port numbers to be specified, as you do)

So if someone came across such a certificate with such a SRV-ID, they could after finding the SAN do a lookup in DNSSEC and verify that this is indeed the correct/current certificate. In some ways this is similar to finding an html page with a 
    <link rel="self" href="http://bblfish.net/"/> 
You could use it to lookup the current version of the page. What you have in your hand is a cached copy.

Now if you do one more little conceptual jump and you allow that one can name things including agents with an http(s) URI then he can put that URI in the SAN field. So I have a WebID 

   http://bblfish.net/people/henry/card#me

Doing a lookup using HTTP will get the meaning of that URI - and so a description of me. That URI could return a PEM certificate too, just as you do in the DNS lookup (we are discussing allowing this in addition to RDF/XML, rdfa, or other XML representations)

   Good so I think we have two protocols - yours and WebID - that both can do the following and that are very similar in those respect:

   1. place an identifier in the X.509 SAN field. 
      - for keyassure this is a service identifier (SRV-ID)
      - for webid this is a URI identifier
   2. dereference the ID to get the latest version
      - using DNS lookup for keyassure
      - using HTTP/HTTPS/ftp... lookup for WebID
   3. Proving authenticity 
   both protocols use the information retrieved canonically at the identifier to prove authenticity.
      - with WebID the relying party uses the public key published there to verify that the agent connecting to it is indeed named by that URI. He is if he could prove in the TLS handshake that he knew the corresponding private key.
      - with keyassure by proving that there is the appropriate link between the keys/signature published in 1-4 and the certificate sent by the TLS server.

   Essentially point 3 - proving authenticity - works because of what you name a trust anchor. I am just pointing out that this trust anchor is tied to a naming system and a canonical lookup procedure in both cases. 

   Ok, so I think that demonstrates quite clearly that there are a lot of similarities. So what is the use of knowing that?

   Well I think for me that helps confirm my WebID intuitions. When I spoke to Dan Kaminsky after his talk "X509 considered harmful" [1] a few years ago, the possibility of something like keyassure helped me feel we could bypass the most damaging of his critiques against the current PKI setup. WebID does not need CAs, and with keyassure web servers won't need them either. We are still left with the clumsy ASN.1 format, but that can be solved over time with better parsers, or, since TLS allows it, to some better defined format such as binary xml perhaps.

   Another advantage of having two very similar protocols developing, especially as they are not stepping on each others toes, is that we may be able to learn a few tricks from one another. So here is one initial idea that occurred to me reading your spec today.

   == IDEA ==

   Currently you are publishing either a signature or a certificate in the DNS. Why not publish the only piece of the certificate that is important: the public key. This is what WebID does. This should be shorter than the certificate, and though it will be longer than the signature, it will be a lot more useful, tying you much less to a particular serialisation format.

  There is no need to send a full certificate. All you need is to tie a name to a public key and to guarantee to the end user the integrity of the information. But the integrity is itself assured by DNSSEC. The tying of the name to the public key is done by the lookup in DNS. So all that is really required is to return the public key - the type and the fields.

  One could then even imagine a TLS improvement where the server would not need to send his certificate either. All the TLS server would need to do is prove that he can encrypt something with his private key. The public key would be fetched from the DNS. So at that point we will have gotten rid of ASN.1 or at least just kept the minimum needed. This would be the server equivalent of the client_certificate_url extension of TLS 1.2 where the client can send a URL to a location of his certificate, instead of sending his certificate. Here the server would not need to send his certificate, and for self signed certificates, the DNS sending the public key would be enough anyway.

  So I hope this helps clarify the similarities of the two protocols as well as the usefulness of our interaction.

> This is not to say that what WebID is doing can't work with the DANE effort, just that we are doing completely different things. DANE is about getting a temporary trust anchor for a particular port/transport/domainname triple for a server, whereas WebID is about identifying clients through an HTTPS lookup. There has been discussion of using DANE to get a temporary trust anchor for S/MIME clients, and that might be extended to doing so for TLS clients, but it would be done using the DNS protocol.

yes, that is where each of us understanding the other could help see where some of these things would fit best. S/MIME it seems to me is closer to client authentication, and so would better fit in with WebID.

	Henry Story

[1] http://blogs.sun.com/bblfish/entry/camping_and_hacking_at_har2009

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 11 Feb 2011 09:14:37 -0500

[Before reading this in the context of 'PKI vendor speaks', I would like to
point out to people on the list that Comodo is now an announced provider of
DNS services under the brand DNS.com.]

It is not very clear to me what is being proposed here.

Let's start from first principles. As far as internet users are concerned,
an Internet user identifier is [email-masked]

I know that there are people trying to peddle URIs as user identifiers but
the success of that approach is evidenced by the fact that OpenID support is
contracting rather than expanding.

Given [email-masked] as the identifier,

DNS is an appropriate mechanism to resolve attributes bound to the '
example.com' portion.

DNS is an appropriate mechanism to use to discover a service that can
resolve the 'user' portion for 'example.com'

DNS is not an appropriate place to store attributes specific to '
[email-masked]'.

We already have a Web Service that is designed to serve as a key centric
distribution mechanism for per-user data and it happens to be a W3C
recommendation - XKMS.

I think it would be entirely appropriate to use DNS assured keys to validate
an XKMS service.

We could also take the XKMS schema and use it within FOAF.

I think that there are many possibilities here. But they are way off topic
for this group.

Would it be possible for people interested in this area to Bar BoF in
Prague?

On Fri, Feb 11, 2011 at 7:19 AM, Henry Story <[email-masked]>wrote:

> I don't think I was far off, but still perhaps too cryptic. In section 2.2
> it states that there are four types of things that can be published in the
> TLSA record
>
> So if in 2 the certificate is a DER encoded X509 cert, then if it is a
> server certificate it should contain according to draft-saintandre the
> Domain Name in the SAN field. There are a few different types of SAN fields:
> DNS-ID, SRV-ID and URI-ID. SRV-ID which is defined by rfc4985 is a lot
> closer to what you are specifying in the RDATA format. (Though it looks like
> that RFC could be improved to allow port numbers to be specified, as you do)
>
> So if someone came across such a certificate with such a SRV-ID, they could
> after finding the SAN do a lookup in DNSSEC and verify that this is indeed
> the correct/current certificate. In some ways this is similar to finding an
> html page with a
> Now if you do one more little conceptual jump and you allow that one can
> name things including agents with an http(s) URI then he can put that URI in
> the SAN field. So I have a WebID
>
> Doing a lookup using HTTP will get the meaning of that URI - and so a
> description of me. That URI could return a PEM certificate too, just as you
> do in the DNS lookup (we are discussing allowing this in addition to
> RDF/XML, rdfa, or other XML representations)
>
>   Good so I think we have two protocols - yours and WebID - that both can
> do the following and that are very similar in those respect:
>
>      - with WebID the relying party uses the public key published there to
> verify that the agent connecting to it is indeed named by that URI. He is if
> he could prove in the TLS handshake that he knew the corresponding private
> key.
>      - with keyassure by proving that there is the appropriate link between
> the keys/signature published in 1-4 and the certificate sent by the TLS
> server.
>
>   Essentially point 3 - proving authenticity - works because of what you
> name a trust anchor. I am just pointing out that this trust anchor is tied
> to a naming system and a canonical lookup procedure in both cases.
>
>   Ok, so I think that demonstrates quite clearly that there are a lot of
> similarities. So what is the use of knowing that?
>
>   Well I think for me that helps confirm my WebID intuitions. When I spoke
> to Dan Kaminsky after his talk "X509 considered harmful" [1] a few years
> ago, the possibility of something like keyassure helped me feel we could
> bypass the most damaging of his critiques against the current PKI setup.
> WebID does not need CAs, and with keyassure web servers won't need them
> either. We are still left with the clumsy ASN.1 format, but that can be
> solved over time with better parsers, or, since TLS allows it, to some
> better defined format such as binary xml perhaps.
>
>   Another advantage of having two very similar protocols developing,
> especially as they are not stepping on each others toes, is that we may be
> able to learn a few tricks from one another. So here is one initial idea
> that occurred to me reading your spec today.
>
>   == IDEA ==
>
>   Currently you are publishing either a signature or a certificate in the
> DNS. Why not publish the only piece of the certificate that is important:
> the public key. This is what WebID does. This should be shorter than the
> certificate, and though it will be longer than the signature, it will be a
> lot more useful, tying you much less to a particular serialisation format.
>
>  There is no need to send a full certificate. All you need is to tie a name
> to a public key and to guarantee to the end user the integrity of the
> information. But the integrity is itself assured by DNSSEC. The tying of the
> name to the public key is done by the lookup in DNS. So all that is really
> required is to return the public key - the type and the fields.
>
>  One could then even imagine a TLS improvement where the server would not
> need to send his certificate either. All the TLS server would need to do is
> prove that he can encrypt something with his private key. The public key
> would be fetched from the DNS. So at that point we will have gotten rid of
> ASN.1 or at least just kept the minimum needed. This would be the server
> equivalent of the client_certificate_url extension of TLS 1.2 where the
> client can send a URL to a location of his certificate, instead of sending
> his certificate. Here the server would not need to send his certificate, and
> for self signed certificates, the DNS sending the public key would be enough
> anyway.
>
> effort, just that we are doing completely different things. DANE is about
> getting a temporary trust anchor for a particular port/transport/domainname
> triple for a server, whereas WebID is about identifying clients through an
> HTTPS lookup. There has been discussion of using DANE to get a temporary
> trust anchor for S/MIME clients, and that might be extended to doing so for
> TLS clients, but it would be done using the DNS protocol.
>
> yes, that is where each of us understanding the other could help see where
> some of these things would fit best. S/MIME it seems to me is closer to
> client authentication, and so would better fit in with WebID.
>
>        Henry Story
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

-- 
Website: http://hallambaker.com/

---

From: Henry Story <[email-masked]>
Date: Fri, 11 Feb 2011 16:06:26 +0100

On 11 Feb 2011, at 15:14, Phillip Hallam-Baker wrote:

> [Before reading this in the context of 'PKI vendor speaks', I would like to point out to people on the list that Comodo is now an announced provider of DNS services under the brand DNS.com.]
> 
> 

I was not proposing anything to start of with, other than to show at what level the protocols are similar. That of course cannot be a proposal, only a point of interest. 

Noticing that similarity was useful in helping me understand what keyassure is doing.  And understanding that similarity also led me to ask why you don't also allow one to publish the plain and simple public key  in addition perhaps to the 4 methods listed in section 2.2 of draft-4. My point there was that that should be enough to do a lot of what you want. See the ==IDEA== section. The supporting evidence for this is that this is enough for us at the WebID level. 

> Let's start from first principles. As far as internet users are concerned, an Internet user identifier is [email-masked]

In WebID we consider essentially an http url such as http://bblfish.net/#me as it is immediately dereferenceable,

> I know that there are people trying to peddle URIs as user identifiers but the success of that approach is evidenced by the fact that OpenID support is contracting rather than expanding.

There are many reasons why OpenId is having trouble. The main one being that the user has to remember what to type, and has to type it. With WebID this is integrated into the SSL layer, so the user only needs to point and click. There is a 4 minute video on http://bblfish.net/ (the second one) that demonstrates this. 

There is a whole list of other reasons why TLS works better, many of them I have gathered here
http://www.w3.org/wiki/Foaf%2Bssl/FAQ#OpenID_failed.2C_do_people_really_want_distributed_identity.3F

> DNS is an appropriate mechanism to resolve attributes bound to the 'example.com' portion.

exactly. DNS is the Canonical lookup method for a DNS name :-)

> 
> DNS is an appropriate mechanism to use to discover a service that can resolve the 'user' portion for 'example.com

yes (though if it can be avoided then that can be better) But it gives some useful flexibility.

> DNS is not an appropriate place to store attributes specific to [email-masked]'.

Completely agree. 

> 
> 
> We already have a Web Service that is designed to serve as a key centric distribution mechanism for per-user data and it happens to be a W3C recommendation - XKMS.

Thanks for pointing that one out. It looks like one of the SOAPy specs. This should be useful.
WebID is working within the linked data architectural space, where you put things at their URI location, and you try to restrict yourself to the RESTful verbs (GET, PUT, POST, DELETE)

> 
> I think it would be entirely appropriate to use DNS assured keys to validate an XKMS service. 

yes, so with WebID we use the DNS assured keys, to power up TLS, so that https becomes a way to validate the foaf document returned - that it has not been corrupted on the way. So that way we have part of the work of what XKMS does, but using simple HTTP. (Need to study XKMS in more detail)

> I think that there are many possibilities here. But they are way off topic for this group. 

Yes.

> Would it be possible for people interested in this area to Bar BoF in Prague?

(I am in Paris btw. But let me know).

Don't forget the issue that I raised that is relevant to this group, namely the idea of putting the public keys in DNS, without all the extra stuff.

Henry

> 
> On Fri, Feb 11, 2011 at 7:19 AM, Henry Story <[email-masked]> wrote:
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 11 Feb 2011 16:24:57 -0500

On Fri, Feb 11, 2011 at 10:06 AM, Henry Story <[email-masked]>wrote:
> In WebID we consider essentially an http url such as
> http://bblfish.net/#me as it is immediately dereferenceable,
>
>

dereference, desmesherence.

What matters to the user is that they have a simple identifier that they can
give to other people, put on letterhead, business cards, read over the
telephone.

Tim didn't intended the URLs to even be visible to the end user. The address
bar was an ad-hoc invention that appeared in Mosaic. In the original
NeXTstep browser you had to dig into a menu to find the url.

If you are proposing infrastructure then make it work for the user first and
only then think about the hacks you might employ for backwards
compatibility.

Here we have the DNS, there is a discovery mechanism that was originally
designed to resolve [email-masked], use it the way it was designed.

If keys are going to be of the slightest use as end user keys they have to
bind to SMTP and Jabber addresses in any case.

What you have here is a URI scheme itself. You should think in terms of the
canonical form being:

webid:[email-masked]

The URL you gave might be something that ended up being a mapping returned
for retrieval/resolution purposes but that is all.

---

From: Jakob Schlyter <[email-masked]>
Date: Sat, 12 Feb 2011 00:10:27 +0100

> DNS is not an appropriate place to store attributes specific to [email-masked]'.

IMHO, that's a pretty strong statement - RFC 4398 (section 3.2) does not agree with you at all.

	jakob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 11 Feb 2011 18:20:05 -0500

The RFC published in 2006

The idea does not appear to have found much success, I am not aware of any
application that obtains S/MIME certs in that fashion.

I think those facts suggest that the DNS is not a good choice for per-user
information.

While that approach may work for small time personal domains, the DNS as
deployed and administered does not make that approach a practical one for an
organization of even moderate size.

---

From: Henry Story <[email-masked]>
Date: Sat, 12 Feb 2011 01:29:26 +0100

On 11 Feb 2011, at 22:24, Phillip Hallam-Baker wrote:

> On Fri, Feb 11, 2011 at 10:06 AM, Henry Story <[email-masked]> wrote:
> 
> What matters to the user is that they have a simple identifier that they can give to other people, put on letterhead, business cards, read over the telephone.

Yes, and I have no problem with that. They can use e-mail addresses, home page urls or other identifiers. No problem. 

> 
> Tim didn't intended the URLs to even be visible to the end user. The address bar was an ad-hoc invention that appeared in Mosaic. In the original NeXTstep browser you had to dig into a menu to find the url.

If you look at the "WebID creation and use in 4 mintues"
http://www.youtube.com/watch?v=S4dlMTZhUDc
you will see that the end user need have absolutely no understanding of the concept of a URI at all. This is completely in line with Tim Berners Lee's vision, and he has in fact sponsored a lot of research on WebID such as "RDF Policy-based URI Access Control for Content Authoring on the Social Semantic Web" http://dig.csail.mit.edu/2009/presbrey/UAP.pdf to just give one example. 

What people give to their friends is a completely different issue. They could give friends e-mail addresses, which could be resolved via Web Finger or other protocols http://blogs.sun.com/bblfish/entry/web_finger_proposals_overview
to the profile document. Or they could use search engines, etc... Those are user interface issues that one should not confuse with issues of logic. 

> If you are proposing infrastructure then make it work for the user first and only then think about the hacks you might employ for backwards compatibility.

Yes, I do recommend you watch my pretty bad and very clearly amateur screen cast "WebID creation and use in 4 mintues"

http://www.youtube.com/watch?v=S4dlMTZhUDc

With some help we can do better.

> 
> Here we have the DNS, there is a discovery mechanism that was originally designed to resolve [email-masked], use it the way it was designed.
> 
> 
> If keys are going to be of the slightest use as end user keys they have to bind to SMTP and Jabber addresses in any case.
> 
> What you have here is a URI scheme itself. You should think in terms of the canonical form being:
> 
> webid:[email-masked] 
> 
> The URL you gave might be something that ended up being a mapping returned for retrieval/resolution purposes but that is all.

I don't think it wrong to use e-mail URLs to identify users. WebFinger does that, and I think they even use DNS to do that - which is better than when they use the .well-known file in http. 

It does not in fact matter how many URIs identify a user. Things can be named by different names. There is a town in Germany the Germans call München, the French and english call Munich. As Frege pointed out in the 19th century Hesperus was known as the Evening Star, Phosphorus as the Morning Star, and it was only recently in human history that these names were shown to all refer to Venus. I have a few different URIs identify me:

http://bblfish.net/#me
http://bblfish.net/people/henry/card/#me
...

So these approaches are all compatible. 

I was trying to show how at the protocol level that keyassure and webid are compatible. This does come to confirm your point that we could place as you suggest webid: URLs in the SAN too if we defined a protocol for webid: dereferencing. This has been proposed on the WebID mailing list, and I am not against it. I just start with the http:// URL example which is easier to understand (once you understand that it requires no typing)

Hope that helps.

   But don't forget the issue I raised of placing a public key in the DNSSEC. 

Henry  

Social Web Architect
http://bblfish.net/

---

From: Jakob Schlyter <[email-masked]>
Date: Sun, 13 Feb 2011 19:49:34 +0100

On 12 feb 2011, at 00.20, Phillip Hallam-Baker wrote:

> The idea does not appear to have found much success, I am not aware of any application that obtains S/MIME certs in that fashion.
> 
> I think those facts suggest that the DNS is not a good choice for per-user information.

I acknowledge it has not found much success, but I would suspect that is also due to the limited email address to DNS domain name mapping used. On the other hand, no other email address to certificate services has found much success either.

> While that approach may work for small time personal domains, the DNS as deployed and administered does not make that approach a practical one for an organization of even moderate size.

Given a better method to provide information on how to perform the mapping between email address and DNS domain name (e.g. all certs for [email-masked] can be found at username._users.kirei.se), I believe this is scalable even for large organizations. If we have that, a protocol like DANE could be quite useful.

	jakob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 13 Feb 2011 18:09:48 -0500

On Sun, Feb 13, 2011 at 1:49 PM, Jakob Schlyter <[email-masked]> wrote:

> > The idea does not appear to have found much success, I am not aware of
> any application that obtains S/MIME certs in that fashion.
> >
> I acknowledge it has not found much success, but I would suspect that is
> also due to the limited email address to DNS domain name mapping used. On
> the other hand, no other email address to certificate services has found
> much success either.
>
> Given a better method to provide information on how to perform the mapping
> between email address and DNS domain name (e.g. all certs for
> [email-masked] can be found at username._users.kirei.se), I believe
> this is scalable even for large organizations. If we have that, a protocol
> like DANE could be quite useful.
>
>        jakob
>
>
As I said originally:

There is already a W3C recommendation that does precisely that - XKMS. It
even has SRV prefixes defined for that exact purpose.