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: Wed, 20 Apr 2011 13:08:56 -0400
Message-ID: <4DAF1328.2050805@openlinksw.com>
To: public-xg-webid@w3.org
On 4/20/11 11:33 AM, peter williams wrote:
> Remember, any decent product manager who has competed in the https space
> (now 15 year old) already knows 80% of the current paper. Honest. Reduce 80%
> of the current material to 1 page, distinguishing in 1 more page the
> remaining 20% "as a twist on existing techniques for validating cert
> messages in SSL handshakes". Imply in that page - by contrast with such as
> the case of PGP certs in GNUTLS https implementation -  that there REALLY IS
> a world of https beyond the X.509 format (and PKIs consisting of CRLS, and
> OCSP, and trust anchors). This world is facilitated by the richness of the
> query-powered semantic web, and its ability to express relations. It can
> chain, better than cert chains (and STS chains, and websso bridges). Just
> look at foaf cards, which are better than the identity pages of openid...
> because they can be properly queried....
> BY talking about a contrast with PGP and then STS and websso... one shows
> one is familiar with the OTHER art in the space, since all those communities
> are pressing on the browsers, too. Its show refinement. It argues for the
> big picture - chaining and relationships... the nirvana of trust chaining.
> That's 2 pages. Max. Take the hint: No-one needs a lecture on the obvious,
> that everyone already does with different method(s). Remember, we have
> competition, pitching for the same space.
> In the next 3 pages, show the changes that enable - the delta from now to
> then. What stops take off of webid, and what 5 features would make 10,000
> independent software vendors excited? Strangely, pick 3 that also benefit
> the STS and websso crowd. Remember, it's a political world, and you need to
> coopt your competition (especially given the munge process, described
> below).
> The 5 CAN be express a dual-use benefit - in that the 5 also "just happen"
> to be enablers for the semantic web. But, they must not look like a foil.
> Play this carefully, as of all the semweb projects ill guess that webid is
> JUST about allowed to present a semweb-themed double benefit enabler list -
> because our pragmatism reputation is such that we are already trusted NOT to
> be bible bashers on the underlying religion or the cult of personality (that
> just turns off many in the community). Remember, the paper is as much about
> tone, as content - especially to the reviewers who will only scan-read it -
> picking who can be trusted not to abuse the opportunity (by bleating on and
> on about their favorite cult).
> If  were choosing, Id be arguing around the inoffensive topic of the foaf
> card (that happens to bring along the semweb with it).

Why not structured profile document where foaf card in an example? To 
many FOAF == RDF == Semweb. Thus, cleaner abstraction will provide more 
protection against knee jerk reactions.

>   Id love for all
> browsers to take the wallet feature they already have (that takes user
> profile info), and a uri of form javascript:aboutme in the address bar
> auto-renders those properties in a window as an HTML/RDFa stream - ready for
> cut and paste. It can already include a cert IN THE cert ONTOLOGY, using the
> "default" cert in the browser cert store. Something VERY simply, that
> "facilitates"... and which can be obviously improved later when websites get
> involved, as the economy boots.

Anything that showcases "cut & paste" remains powerful re. Web oriented 
bootstrap pursuits.

> Its tempting to treat the paper as an exam, to get to the conference and
> speak in corridors (and one's 20m) on content OTHER than that in the paper.
> Ive seen that done many times.  But remember, the final method is to take
> the 5 points FROM THE PAPER for the top half of contributions (as examined
> orally, in 20m), and do a union. This union munge will be what all browser
> vendors do. If webid gets 2 out of its 5 enablers on that list, that would
> be a miracle. But, THIS IS YOUR GOAL - have 2 (of 5 suggestions) actually go
> global.
> Now, what would I do with my magic wand, if I had one, and its two wishes?
> (or magic lamp, perhaps)

Find a way to show the finished Cake as early as possible. Then let 
audience drive the drill-down to details associated with ingredients and 
baking process :-)

> Be known in the paper
> -----Original Message-----
> From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
> On Behalf Of Henry Story
> Sent: Wednesday, April 20, 2011 6:57 AM
> To: Harry Halpin
> Cc: public-xg-webid@w3.org
> Subject: Re: Position Paper for W3C Workshop on Identity
> On 20 Apr 2011, at 15:48, Harry Halpin wrote:
>> +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.
> The paper can only be 5 pages long. Screenshots take a lot of place. We were
> thinking of going into details in the presentation, where I hope we can get
> a bit more time than 20 minutes.
>>    cheers,
>>      harry
> 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 Wednesday, 20 April 2011 17:09:19 UTC

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