[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