[foaf-protocols] Conversation with Henry about WebID

Melvin Carvalho melvincarvalho at gmail.com
Tue Sep 21 00:00:31 CEST 2010

On 20 September 2010 19:57, Henry Story <henry.story at bblfish.net> wrote:

> On 20 Sep 2010, at 16:16, Melvin Carvalho wrote:
> > Had a conversation with henry discussing various points that have been
> > discussed lately:
> >
> > Here's what we talked about
> >
> >
> > 1. Ease of publication of Public Key
> > ====================================
> >
> > Essentially we would like to associate a webid with a public key, as
> > accurately, and in a way that make life as easy as possible for
> publishers.
> >
> > I argued that this is an important enabler to getting wider publication
> and
> > adoption of public keys on the web, and webid in general.
> >
> > Pushback from google has been to simplify predicate names to make things
> > easier for them, leading to publication of all gmial accounts as FOAF.
> >
> > Feedback from facebook, who considered using FOAF, wanted to have all
> their
> > term in one namespace, leading to wide adoption of RDFa and OGP.
> >
> > The public key is normally just one variable triple with some scaffold
> > around it.  Simplifying the scaffold would *seem* to be desirable, tho
> > ideally it would be good to have some push back from large communities
> > driving things.
> Yes, so if some big players come up and say they will adopt
> WebId if there are certain relations named in certain ways
> one should at that point listen carefully to their suggestions.
> Is there any player here such as identi.ca that is in this
> position? Trying to second guess them is not going to be very
> fruitful as we are very likely to miss guess, and they may also
> change their mind on interacting with the community - they
> may have misunderstood something after all.
> > 2. Direction of cert:identity
> > ======================
> >
> > We both seemed to agree that a 'rev' association between webid and
> > cert:identity seemed unintuitive, and maybe something to reverse.
> >
> > Henry suggested the community trying to come up with a good consensus
> here.
> Again it would help if our community had some big players.
> > 3. WOT Ontology
> > ===============
> >
> > I suggested there's an overlap between wot:PubKey and some of the
> ontologies
> > we're using.
> >
> > Henry rightly pointed out that this should not be drawn into the WebID
> spec,
> Well some of those can make sense in the cert ontology. The cert ontology
> should be able to describe certificates of all kinds, including pgp keys.
> There is not that much point maintaining both the cert and the wot
> ontologies.
> > but is a different conversation, and also that some of the WOT terms
> could
> > be misleading.
> the wot:hasKey links a person to a wot:PubKey, which is not defined to be a
> "represent a PGP/GPG public key". But PGP/GPG keys are really certificates.
> cert:Certificate covers that.
> >
> > I'm going to look further at this, with a view to trying to help bring
> out
> > WOT 0.2 in parallel,
> What would be interesting to understand is your motivation to work on
> wot 0.2? Why do you think developing that is going to get more people on
> board? What is missing in the cert ontology? That is what is not so clear.

Trust and reputation on at Web Scale have always been my major interests,
which lead me first to OpenID, then to WebID, as a key facilitator.  In the
client server model the client trusts data because they have a certain
degree of trust in a server.  In a decentralized model, any WebID can sign
any piece of data, and the client can trust a WebID as a new layer of trust,
to the web.  This is the area that interests me most, as I think it will
lead to much more distributed web technologies ... time will tell whether
this will be useful or not, but at a minimum, I will use it, so that
motivates me.

As I understand it the WOT vocabulary is the historical place where a web of
trust style of assertions and signing was happing (it predates xmlsig and
webid), so it seems a logical place to be looking at improving.  Now seems a
good time to get that ontology into shape in light of the standardization of
WebID and, to a lesser extent, RDFa.

> > but it's work that's not a pre requisite for the WebID
> > protocol, and we should not distract too much.
> >
> >
> > *4. FOAF Vocab
> > ==============
> >
> > *I argued that WebID is tied to foaf:Agent already an that public key
> should
> > become a first class citizen of your FOAF profile just as phone number,
> and
> > email is today.
> >
> > My suggestion has been to try for some top level shortcuts into FOAF
> which
> > could possibly encode a public key in as little as one triple (for
> example
> > using PEM).  This is perhaps similar to FOAF adding skype as a shortcut
> > triple or other such items.
> >
> > There's obviously pros and cons to this approach, but something to think
> > about.
> >
> >
> > This aside, it's important that we continue to work on interoperability
> and
> > implementations.  I've said that I'm happy to support varied encodings of
> > public keys, as I have to do the work as a one-off in a library, but the
> > benefit is potentially possible to a large number of publishers.
> What we need to do is move from potential benefit to measured and argued
> benefit.
> Developing new ontologies is not I perceive yet the problem we are having
> with
> adoption. It is more that we need more working use case to show off the
> power
> of what we are doing.
> Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20100921/0cbff198/attachment-0001.htm 

More information about the foaf-protocols mailing list