W3C home > Mailing lists > Public > public-webid@w3.org > May 2014

Re: A WebID Implementation => HTTPS Client Certificate Authentication lacks a useful filter mechanism.

From: <henry.story@bblfish.net>
Date: Tue, 20 May 2014 06:03:59 +0200
Cc: "Kingsley (Uyi) Idehen" <kidehen@openlinksw.com>, "public-webid@w3.org" <public-webid@w3.org>
Message-Id: <BEDD192E-5847-4E43-AC3D-674E9A0842ED@bblfish.net>
To: Mo McRoberts <mo.mcroberts@bbc.co.uk>

On 20 May 2014, at 01:13, Mo McRoberts <mo.mcroberts@bbc.co.uk> wrote:

> On  2014-May-19, at 23:05, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>>> For WebID-X.509 a specific WebID policy OID would be ideal since it
>>> doesn't interfere with anything else.
>> And that would change what in regards to Browser behavior, in their current form?
> Browsers which implemented it would only prompt for selection of certificates containing the extension which the server said it wanted (similarly to how the list is filtered now if you request client certs from specific CAs, but without it being so horribly kludgy).

The only way I know of for server to signal something about certificate selection to the client is via the
certificates_list message. This was explained in more detail in ISSUE-62, in this message for example:


( for some of the debate
  http://www.w3.org/2005/Incubator/webid/track/issues/62 )

I still don't think we have really done enough testing to see if we can't really build
something that cleverly uses this feature of TLS, and after specifying a WebID DN resolve this problem. 

> Browsers which didnít implement it would behave as they do now.
> Itís very sensible, and Iíd love to see it happen ó though Iím not about to hold my breath.

How would this OID be used in a request from the server to the client? Does that require a change
in the TLS protocol? Do you think we could get by with the above mentioned proposal?

> M.
> --
> Mo McRoberts - Chief Technical Architect - Archives & Digital Public Space,
> Zone 2.12, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA.
Received on Tuesday, 20 May 2014 04:12:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:05:55 UTC