W3C home > Mailing lists > Public > public-webpayments@w3.org > April 2013

Re: Webkeys, OpenID, WebID, OAuth etc..

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sun, 21 Apr 2013 22:30:33 -0400
Message-ID: <5174A0C9.4090205@digitalbazaar.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
CC: "public-rww@w3.org" <public-rww@w3.org>, Web Payments CG <public-webpayments@w3.org>
On 04/21/2013 09:57 AM, Melvin Carvalho wrote:
> 3. No URLs for keys, making it non-trivial to figure out which key 
> signed a message.
> 
> Keys *can* have URLs as per the cert ontology.  They can be blank
> nodes too, which I think is currently more common.  I use a URL.

It's Linked Data, you *can* do anything. The question here is MUST. In
Web Keys, keys MUST have a URL. That requirement makes it so that you
can depend on that URL when verifying digital signatures.

> Since TPAC 2012 we have decided to decouple WebID into Identity and 
> Authentication specs.

That's a good approach.

> Currently the cert ontology is able to related a key to a foaf :
> Agent via the "key" predicate.  It cannot (yet) do accounts, though
> I requested it last month, but coming to consensus on how to name
> things can sometimes be a challenge :)

True, although the naming/vocabulary part is the easy bit... it's the
protocol that's the hard problem.

> Do you need the agent -> key relationship or the account -> key 
> relationship, or both?

Depends on what you mean by Agent. Web Keys requires that the public key
specify the owner and that the owner specifies ownership over the public
key. If you don't verify both, you have a security issue on your hands.

> It seems both efforts have evolved in the last couple of years.  And 
> sounds like there's a lot in common still, maybe it's still possible
> to iron out the differences ... so that each can reuse from the
> other.

We tried to work with the WebID community two years ago by:

1. Writing the first version of the WebID specification (I did that).
2. Creating an implementation of WebID over TLS in JavaScript+Flash and
   then creating one in JavaScript+WebSockets.

We spun our wheels for more than a year trying to convince the community
that the approach of client-based certificates was a dead end unless the
browser vendors got on board. Here we are two years later and the
browser vendors still aren't on board, which underlines why we were
concerned with the approach. Unless the community is willing to
reconsider that position, which Henry is making very clear isn't going
to happen, I don't think there is much room for collaboration.

There is the Vocabulary problem and Publishing an Identity problem, but
those are easy problems to solve. The solution that we end up in the end
will be the one that resonates the most with Web Developers, and we're
not too concerned about which one is picked because not much is at stake
there. In the very worst case, since this is Linked Data, an implementer
could implement both without much pain. The hard problem have, and have
always been, the protocol and the UX.

If there is some place that you feel we could collaborate, please let us
know, but I'm not really seeing where that would be at the moment. We're
really not interested in having another repeat of what happened two
years ago.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/
Received on Monday, 22 April 2013 02:31:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:23 UTC