RE: Position Paper for W3C Workshop on Identity

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








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

Received on Wednesday, 20 April 2011 03:06:02 UTC