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

On 4/21/13 9:57 AM, Melvin Carvalho wrote:
>
>
>
> On 17 April 2013 21:20, Manu Sporny <msporny@digitalbazaar.com 
> <mailto:msporny@digitalbazaar.com>> wrote:
>
>     On 04/16/2013 02:41 PM, Melvin Carvalho wrote:
>     > I just read:
>     >
>     https://hacks.mozilla.org/2013/04/web-payments-with-payswarm-identity-part-1-of-3/.
>     >
>     >  Of the four points listed below, where does WebID+TLS fall short?
>     >
>     > 1. It must be decentralized. 2. It must support discoverability by
>     > using a resolvable address, like a URL or email address. 3. It must
>     > support, with authorization, arbitrary machine-readable information
>     > being attached to the identity by 3rd parties. 4. It must be able to
>     > provide both public and private data to external sites, based on who
>     > is accessing the resource. 5. It must provide a secure digital
>     > signature and encryption mechanism.
>     >
>     > I think it's perhaps (5)
>     >
>     > Also iirc (and I could be wrong on this) the UX for WebID + TLS
>     > using client certs was not considered optimal for users with limited
>     > technical knowledge ...
>
>     Hi Kingsley, Jürgen, Melvin,
>
>     You will notice that the Web Keys spec builds on a number of the good
>     parts of WebID while stripping out the bad parts of WebID.
>
>     The good parts of WebID that also exist in Web Keys:
>
>     1. Decentralized design.
>     2. Uses URLs to identify things.
>     3. Uses Linked Data to express information.
>     4. Access Control Lists via public/private crypto.
>
>     The bad parts of WebID:
>
>     1. No explanation of how to do digitally signed messages.
>     2. No explanation of how to encrypt messages, deferring to TLS
>        instead (which may not always be available).
>     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.
>
>     4. Expression of modulus and exponent in raw form, making it difficult
>        for developers to feed those values to common encryption libraries.
>     5. Key registration is not covered in the specification.
>     6. Unnecessarily coupled with TLS client-cert protocol.
>
>
> Since TPAC 2012 we have decided to decouple WebID into Identity and 
> Authentication specs.
>
>     7. Bad UX using client certs with browser makers not committed to
>     making
>        the experience better.
>
>     The parts that don't exist in WebID, but do exist in Web Keys:
>
>     1. Creating digital signatures for JSON-LD-based messages is covered.
>     2. Encrypting JSON-LD-based messages is covered.
>     3. Using a Web Key to do digital signatures for HTTP requests is
>        covered (HTTP Signatures), allowing you to do digitally signed
>        GETs on resources.
>     4. Keys can have URLs, and owners - for example:
>     https://dev.payswarm.com/i/manu/keys/1 is owned by
>     https://dev.payswarm.com/i/manu
>
>
> 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 :)
>
> Do you need the agent -> key relationship or the account -> key 
> relationship, or both?
>
>     6. Key generation and registration is covered in the specification.
>     7. TLS is never required for Web Keys clients (but is required for Web
>        Keys servers). No dependence on client-side certs (which are
>     hard to
>        install and manage for beginners).
>     8. Keys are expressed using PEM-encoded form, making them easy to
>        drop into most common cryptography libraries.
>
>     We did try to build PaySwarm on top of WebID in the beginning. When it
>     became apparent that there were issues with the WebID protocol
>     that made
>     it impossible to build a payment solution on top of it, we came
>     back to
>     the community with several change requests that were eventually
>     rejected.
>
>     Since we needed a solid identity solution for the Web Payments
>     work, we
>     decided to take the good parts of WebID and use it as a basis for what
>     eventually became Web Keys.
>
>     The Mozilla Hacks post on identity only covered the requirements at a
>     high-level. The items above are really what we needed from an identity
>     solution for Web Payments. Hope that explains it in a bit more detail,
>     if you'd like me to elaborate on any of the points above, please
>     let me
>     know and I'd be happy to do so.
>
>
> 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.
>
>
>     -- 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/
>
>

Manu,

There's too much squeezed into your response to properly answer my 
question, hence my "deafening silence". I suggest we present these 
matters in tabular form as its the only way for real clarity to emerge.

Please the following mini glossary:

1. WebID -- an HTTP URI that denotes an Agent
2. WebID profile document -- a FOAF profile based profile document that 
describes an Agent denoted by a WebID
3. WebID+TLS -- a TLS based protocol that adds profile lookup and 
public-key + WebID matching to HTTPS .

The weaknesses I see in WebID (hence our use of the moniker NetID) are 
as follows:

1. HTTP URI specificity
2. FOAF vocabulary specificity .

In reality, the items above are somewhat artificial as neither is really 
a kernel level enforcement that stops the concept being applicable to 
the Internet at large etc..

At the RWW level we are going to have:

1. a variety of Identifier types for denoting Agents
2. a variety of authentication protocols for identities
3. a variety of access control lists and data access policy mechanisms.

The only constants will be:

1. RDF model for Entity Relationship Semantics -- which has First-order 
logic as its schema, subject->predicate->object syntax; a variety of 
syntax notations (e.g., Turtle, JSON-LD, RDFa, Microdata, RDF/XML etc..) 
; and a variety of data serialization formats (e.g., Turtle, JSON-LD, 
RDFa, Microdata, RDF/XML etc..)

2. Webby Structured Data -- i.e., RDF model based Linked Data where URIs 
that denote entities resolve to RDF model based description documents.


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen