W3C home > Mailing lists > Public > public-xg-webid@w3.org > April 2011

Re: Position Paper for W3C Workshop on Identity

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Sat, 23 Apr 2011 16:53:04 -0400
Message-ID: <4DB33C30.7000803@openlinksw.com>
To: public-xg-webid@w3.org
On 4/23/11 1:10 PM, Henry Story wrote:
> Peter could I ask you to take a Web point of view - global names, no center of control, linked
> data space, RESTful architecture - and tell us what the problem with AAs are, why they are not
> used on the global web (but only in companies, or locally) and how WebID tied into web
> technology can bring an advantage that could bring the benefit of the same idea to a global
> scale?
> This is a useful exercise I think. It's what I do when I come across a technology
> that did not succeed. I see if there is something new that has appeared that could
> be a game changer.

I really think the "pick things up and put them down" ad says it all 
i.e., we read and write data to and from addresses. URIs enable us to do 
this at InterWeb scale, and via the HTTP scheme, REST-fully :-)


1. http://youtu.be/3FGZvFZdVbk -- I lift things up and put them down AD .

> Henry
> On 22 Apr 2011, at 21:41, peter williams wrote:
>> If you read the X.509 standard (it may be time...folks!) you will learn that
>> there is a parallel structure called the attribute certificate. It has a
>> different set of issuing dynamics and control system interplays to the cert
>> you play with in SSL (known as an X.509 identity certificate). It's
>> hertitage is the Kerberos PAC, which was a refinement of the ECMA PAC from
>> 1984. Arguably, the websso assertion trumps all PACs blog formats, being
>> little more than a PAC in signed XML - dynamically minted. The SAML
>> attributeQuery delivering a signed AttributeResponse was intended by SUN
>> originally to be an endpoint, that fronted a directory call (abstracting the
>> ldap/OSI stuff behind a web method)
>> So, yes, today millions/billions of times a day (in windows), client certs
>> called the COMPUTER$ cert are consumed in DEC/RPC sessions, and the local
>> directories whose endpoints are learned using Ethernet broadcast discovery
>> supply attributes (about the workstation PC, itself). With SOAP, one does
>> the same thing on the web for users (rant alert, mentioned SOAP/RPC), where
>> the SOAP interceptor makes the directory calls, using some fast protocol
>> (not ldap!). Or, it pings a foaf card, instead , to the same effect - since
>> the foaf card is little more than a serialized directory record - an ldif
>> entry in a new syntax, stuffed on a URI endpoint. To be fair, the foaf card
>> has more advanced logic than the X.500 information model (but not THAT much,
>> note, since 1992).
>> So, It's not right to say there is any "improvement" over X.509 yet, That's
>> a false claim to make (in an academic conference, anyways). There is an
>> alternative embodiment (in patent speak, license still required). You don't
>> get to claim (validly) any originality, though, or improvement over previous
>> disclosed art. In fact, failure to properly discuss the prior art in webid
>> land is showing a certain lack of "proper" teaching ability (which is what
>> patent examiners are really looking for, in non US patents). Folks are not
>> generally showing the path of innovation - implicitly denying all that went
>> before, often.
>> Now, this is good, as it means it's harder for folks to patent
>> "re-inventions". But, its hard on the ego, as all we are doing is
>> re-packaging and re-tuning. There is not much science, its mostly
>> engineering - which is not to say that there should not be Engineering
>> recognition!
>> -----Original Message-----
>> From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
>> On Behalf Of Henry Story
>> Sent: Friday, April 22, 2011 11:00 AM
>> To: WebID XG
>> Cc: Jeff Sayre; Alexandre Passant
>> Subject: Re: Position Paper for W3C Workshop on Identity
>> So one feedback I have had shows that we need to tune a little bit the
>> understanding of how
>> the user can control not just his name but the attributes about him.
>> This is in fact another improvement of WebID to X509, and an important one
>> that explains
>> why we can go so much further. In usual usage of X509 certs all the
>> information
>> passed around was in the cert. True it was designed to be a pointer to an
>> X500 DB, which would
>> contain the further information (and which could still work that way of
>> course).
>> Instead we use Web Based Access control and Hypermedia as the Engine of
>> Application State [1]. Perhaps that
>> is something we can get in there. We can have the profile link to or return
>> more or less depending on the
>> identity of the requestor.
>> I think that can be tied into the assurance story too.
>> I'll try to work that story in.
>> 	Henry
>> [1] I found this article on the subject but have not yet read it carefully
>> http://www.peej.co.uk/articles/hypermedia-as-the-engine-of-application-state
>> .html
>> On 22 Apr 2011, at 12:42, Henry Story wrote:
>>>  From yesterdays comments I have now tweaked the paper to the following
>>> http://bblfish.net/tmp/2011/04/22/
>>> I think we really are there, it reads very well now, is clear, open to new
>> protocols (ldap included),
>>> makes friends in the TLS, dane, openid and freedom box community, whilst
>> also showing
>>> the government how they can get some of what they want for little cost
>> (important
>>> in the government cut back season, when Democratic presidents have to work
>> with Republicans).
>>> I'll  start passing this to members of this group who are not
>> participating
>>> here so actively, probably due to combined reason of volume of mail  and
>>> holiday season, to see if we can get some other feedback, some other
>> points of
>>> views.
>>> We can review some of this on Monday.
>>> Henry
>> Social Web Architect
>> http://bblfish.net/
> Social Web Architect
> http://bblfish.net/



Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
Received on Saturday, 23 April 2011 20:53:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:44 UTC