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

On 04/21/2013 02:30 PM, Kingsley Idehen wrote:
> 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.

Ok, responses below.

> 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 .

The weaknesses we see in WebID are:

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 REQUIRED URLs for keys, making it non-trivial to figure out which
   key signed a message.
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
   (it's the only implementation of the protocol).
7. Bad UX using client certs with browser makers not committed to making
   the experience better.
8. No way to digitally sign HTTP requests.
9. Key generation and registration is left open-ended in the spec.

> 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..

The problem isn't with the concept, it's with the execution in WebID.

> 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.

Yep.

> 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.

Yup.

What we're trying to do with Web Keys is provide a "best-practice"
simple mechanism for authentication that can be employed today on top of
HTTP 1.x, without a requirement for TLS, and without a requirement for
client-side certs.

Web Keys is not focused on the problem of browser-based login as the
Mozilla Persona folks have that well under control and Web Keys can
build on top of that mechanism.

-- 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:39:01 UTC