Re: How to request a WebID?

Are we really saying that webid has no real expectation of having a major social impact until 3-5 years time?

This places it in the research category. Knowing this, no browser vendor is going to prioritize work necessary for webid very high (it probably won't even make the list, at all, to be honest, at that timescale). I cannot see the team working on ie10 even putting webid on the feature list, given this expectation.

In the next 3-5 years, we will have to just make do tgen with building on the 1996 era client certs capabilities shared by browsers, when operating in Mozilla-compatability mode. 10% of web users still use windows xp and it's ie browser: so we are somewhat limited by legacy browsers, too. It's the Mozilla-comparability of 5 years ago that defines the baseline for testing.

Things would be better if we were using smartcard-powered certs, since that infrastructure evolved further, upto 2000 ish (all in prep for mandatory key escrow in the uk, us, france etc). It went far enough to support major military smartcard deployments, based on commodity browsers, suitable for intranet sso to the LAN, using client  certs and https (and military ciphersuites, not rsa). There may be features on common browsers here we can repurpose, being richer than the older digitalid capabilities based on software crypto.

On Apr 6, 2011, at 1:39 AM, Henry Story <henry.story@bblfish.net> wrote:

> 
> On 5 Apr 2011, at 17:46, Peter Williams wrote:
> 
>> What name will you choose?
> 
> That is of course something we need to agree upon, and all be very serious about doing exactly correctly.
> I think we then need:
>  - language for the spec
>  - a good test suite to verify the implementations
> 
> Currently I am using
> 
> static final String issuer = "O=FOAF\\+SSL, OU=The Community of Self Signers, CN=Not a Certification Authority"; 
> 
> Perhaps we could now get a W3C ID.
> 
>> Will it mean any thing to 1 billion users in china? Will Russians object to the use of roman characters? Why cannot Thai folk see Thai style writing?
> 
> That has never been a problem. 
> They seem happy to use the web, where the main verbs are GET, PUT, POST and delete. 
> 
>> 
>> 2 modern, professional choices:
>> 
>> Have all certs bear a common cert policy oid, with accompanying uri.
> 
> "Modern", "Professional" is empty marketing jargon that belongs on chewing gum packets
> http://blogs.sun.com/bblfish/entry/professionnel
> 
> What we are trying to deal with here is how to get the browsers to only show specific certificates to their user. The only implemented mechanism we know of until know is the one available in the SSL Certificate Request Message, certificate_authorities field. This allows a certificate request to list a number of certificate authorities, of which one could be the WebID cert.
> 
> We could also put a small paper together to suggest futher TLS improvements for WebID which would solve these problems. Though that will probably take 5 years to succeed: 1-2 years for WebID to be deployed enough for the skeptics to take it seriously enough to start an IETF group. 1-2 years for that group to produce the spec. 2 years for the browsers to implement. 3 years for enough browsers to have shipped for it to be useful. (some of these can go on in parallel)
> 
>> Have all certs bear an application policy oid , like 50 windows apps using https exploit to segment the https world into 50 variants of https - with different discovery/validation/revocation practices per appid.
>> 
>> Both suggestions require v3 certs, which hurts use of v1 certs.
> 
> Do any of those work in current browsers to restrict the choice of certificates?
> 
>> 
>> In the v1 world, one played tricks. If the issuer name had rdn with oid of x.y.z do not display it (by definition) bur use it as a discriminatory. This was acceptable as the resolver indicated which rdns in the name were distinguished, and which were merely non security enforcing hints.
>> 
>> Make sure it works when non browser https clients are using webids (such as servers accessing sparql endpoints).
>> 
>> 
>> On Apr 5, 2011, at 6:31 AM, Henry Story <henry.story@bblfish.net> wrote:
>> 
>>> 
>>> On 5 Apr 2011, at 15:01, Nathan wrote:
>>> 
>>>> Hi All,
>>>> 
>>>> A possible issue, how does a server specifically tell a client that it's trying to auth with WebID?
>>> 
>>> This is ISSUE-15: Native browser-based WebID-only certificate display
>>> 
>>> (the name could do with improvement)
>>> 
>>>> 
>>>> Let's suppose for a moment that somebody else comes up with (or already uses) an authentication protocol which also uses client side certs as identifiers, let's call is SSL-ID.
>>>> 
>>>> In my browser I have 2 certificates, my WebID one, and my SSL-ID one, so:
>>>> 
>>>> 1) how does a server inform the client that it's requesting a WebID or an SSL-ID?
>>>> 2) how do I (as a user) know which to select, when all that's presented is a "please select your 
>>>> certificate"?
>>> 
>>> If all WebId enabled certificates that were self signed used the same DN then one could
>>> use the build in certificate selection mechanism of TLS
>>> 
>>> This was brought up here initially by Bruno Harbulot:
>>> http://lists.foaf-project.org/pipermail/foaf-protocols/2009-April/000450.html
>>> 
>>> It would require us to come up with such a DN, and for all WebID generated certificates to place those
>>> in the Certificates.
>>> 
>>> There is an issue of how this would be compatible with CA issued certs with WebIDs too. There we should perhaps recommend a TLS protocol improvement.
>>> 
>>>> 
>>>> We may need to address this, or include technologies which cater for this (I can't think of any off the top of my head, but then I haven't looked or paid attention to this use case yet - may follow up later if I find some).
>>>> 
>>>> Best,
>>>> 
>>>> Nathan
>>>> 
> 
> 
>

Received on Wednesday, 6 April 2011 15:38:20 UTC