Re: Position Paper for W3C Workshop on Identity

On 4/20/11 9:48 AM, Harry Halpin wrote:
> On 04/20/2011 05:00 AM, peter williams wrote:
>> Ok. But don't forget, almost everyone of the claims made there have been
>> made for alternative means of validating digital id certs, using 
>> chains of
>> trust linking trust points in a name space. Despite what it says 
>> about TBL
>> inventing webid etc, at this point (10 years after he invented 
>> validating
>> certs by lookup), there are still more ldap nodes in existence with a 
>> cert
>> in them than foaf cards.
>>
>> Also remember, many of the browser vendors do work for US DoD.
>> Mozilla's/Netscape's support for s/mime and ssl from netscape 4.0 
>> onwards
>> was entirely driven by DoD - using it for millions of [office] users 
>> to do
>> intranet logon, using cert-powered smartcards. These certs validated 
>> using
>> OCSP, as directed using a URL in the cert which invites the certificate
>> using system to obtain a signed response from that endpoint ...about the
>> cert status. All the vendors are intimately aware of these features 
>> (even if
>> we here are not, or tend to be in denial about their value, not being 
>> RDF).
>>
>> Here is what I would say:
>>
>> The client cert authn features in current browsers are focused on 
>> intranet
>> logon. They need to support internet sites, too.
>>
>> The message from the SSL server hinting at which certs should be 
>> shown in
>> the cert picker needs improving, and standardizing across vendors.
>>
>> A javascript method needs to be exposed that allows the browser to 
>> destroy
>> client side SSL state (as happens in IE, but its not javascript 
>> powered).
>> Ideally, this would be selective (by server cert fingerprint say)
>>
>> Javascript methods need to enumerate SSL sessions and their state
>> information to controls, and to toolbar APIs similarly.
>>
>> Javascript callbacks (ajax patterns...) need to be able to consult 
>> the state
>> of SSL sessions and connections. Ideally, javascript libraries would 
>> round
>> out ways of interacting with SSL connections.
>>
>> The dom model would expose the SSL sessions and connections in effect 
>> for
>> rendered content, distinguished from the SSL sessions and connections 
>> linked
>> to the DOM instance by callback identifiers, etc.
>>
>> Tabs needs to handle client cert separately, since a user may wish to
>> present to one site his X.509 chained cert (with full extensions etc),
>> whereas to another site he may want to present his/her webid with a
>> self-signed certified version of the same modulus
>>
>>
> +1. All of these seem like fairly sensible low-hanging fruit that(I 
> hope!) browser vendors would be interested in. So if the position 
> paper could talk about WebID, and then have something around this last 
> as *action items*, then
>
> The only issue may be standardizing UX across vendors, which is hard 
> as of course browser vendors compete re UX. But saying "something 
> should happen" (think "download buttons") is great, and then pointing 
> how how terribly unintuitive current cert handling UX is and how parts 
> of it (i.e. the tab handling) are just missing.
>
> If this was accompanied by screenshots across different browsers, I'd 
> be very, very happy.

Re. screenshots, I dumped a few last year when testing WebID and ODS 
[1]. If that helps etc..


Links:

1. http://twitpic.com/photos/kidehen?page=3 -- basically page 3 onwards 
re. screenshots Chrome, IE, Safari, FF, and possibly Opera

Kingsley
>
>    cheers,
>      harry
>
>
>
>>
>>
>>
>>
>> -----Original Message-----
>> From: public-xg-webid-request@w3.org 
>> [mailto:public-xg-webid-request@w3.org]
>> On Behalf Of Jeff Sayre
>> Sent: Tuesday, April 19, 2011 4:26 PM
>> To: Peter Williams
>> Cc: WebID XG
>> Subject: Re: Position Paper for W3C Workshop on Identity
>>
>> Peter, thanks for your comments.
>>
>> The way that I understand the purpose of the position paper is that 
>> it needs
>> to be sufficiently enticing and relevant so that our project is 
>> selected to
>> present a 20-minute+ presentation at the workshop. Thus the paper is not
>> intended to be that technical in nature.
>>
>> Assuming we are offered a slot, our presentation will be more technical.
>> But even then, we cannot show browser vendors what they need to do in 
>> their
>> browser code to enable minimally-viable WebID support. For instance, 
>> we will
>> not be providing the code changes required to be made to each browser 
>> core
>> in order to offer a logout button for WedID.
>>
>> Our presentation and demo will give them a solid understanding of WebID.
>> It will then be up to each browser vendor to offer their version of 
>> WebID
>> support--I assume (hope) with some additional assistance from our group.
>>
>> This workshop is targeted toward browser vendors. It is an 
>> opportunity to
>> enlighten them to the virtues of WebID and inform them in the ways 
>> that they
>> can assist in its adoption and use.
>>
>> Jeff
>>
>>> I read it.
>>>
>>> I have no idea what changes are required in my browser (a variant of
>>> ie, rendered in a windows form) to enable better webid support. I know
>>> all about webid, identity mgt, and the better world to come.
>>>
>>>   Folks should be aware that in the windows world, ie is also a
>>> component - allowing folks (like me) making classical windows clients
>>> (doing soap and cloud rest) to build-your-own-browser -where ie does
>>> 80% of the work, and custom providers and event handlers (and
>>> surrounding ui designed by me) does the rest. Our browsers showing
>>> HTML and linking have no buttons, no frame ... By default, unlike  the
>>> ie packaged by Microsoft  and profiled to behave rather like Mozilla.
>>> Our ie has different roots, different thus, that and the other.
>>>
>>> If I don't get it, nor will the main browser vendor. I don't know what
>>> 5 things to change to enable this group.
>>>
>>>
>>>
>>> On Apr 19, 2011, at 3:03 PM, "Jeff Sayre"<jeff@sayremedia.com>  wrote:
>>>
>>>> The submission deadline for position papers for the W3C Workshop on
>>>> Identity has been pushed back to next Wednesday, April 27 (it was
>>>> this Friday, the 22). This is good.
>>>>
>>>> For those that are interested, please take the time to read through
>>>> it before our next WebID IG telecon this coming Monday. We can
>>>> discuss it then and approve it before it is officially submitted.
>>>>
>>>> It is still a draft. Henry and I will be working on it tomorrow,
>>>> trying to finish it up. So, I would suggest waiting until the end of
>>>> this week to take a look. I'll try to remember to send out an email
>>>> when it is ready to review. Of course, please feel free to join in
>>>> before then!
>>>>
>>>> Jeff
>>>>
>>>>> Here is the link for the Google Doc's Draft WebID Position Paper for
>>>>> W3C Workshop on Identity. It is just the beginning of what will
>>>>> become a more meaningful document. As I will not be able to make it
>>>>> to next Monday's meeting, I plan on putting as much time as possible
>>>>> this week into the position paper.
>>>>>
>>>>> https://docs.google.com/document/d/1L-PhczWNSciUIRCfsK92wRbxJEU1kKSw
>>>>> UcxFSz3DAu0/edit?hl=en&authkey=CJv5nPIJ
>>>>>
>>>>> Jeff
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
>
>
>


-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

Received on Wednesday, 20 April 2011 14:04:34 UTC