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

On 4/21/13 10:38 PM, Manu Sporny wrote:
> 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.

We should separate implementation from the concept. I've advocated that 
for eons.
Conflation never works, just look at what it's done to:

1. RDF
2. Semantic Web vision
3. Semantic Web project.

The same conflation started creeping into Linked Data once the LOD 
effort grained traction via DBpedia [1] and the resulting LOD cloud [2].


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

Okay.

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

Persona handles verifiable identity but it falls way short when it comes 
to being able to use it (off the bat) for entity relationship semantics 
driven Web resource ACLs. We make it work in our solutions because we 
support a variety de-referencable URI schemes [3][4][5][6].

Links:

1. http://dbpedia.org/About -- DBpedia
2. http://lod-cloud.net/ -- LOD Cloud
3. http://bit.ly/M7hd4T -- constraining access to a SPARQL endpoint
4. http://bit.ly/NmGbMZ -- similar but scoped to constraining access to 
resources from storage services
5. http://kingsley.idehen.net/DAV/home/kidehen/ -- my personal data 
space front-door showcasing multi-protocol based identity verification 
and acls
6. http://bit.ly/UXZEYV -- multi-identifier and multi-protocol based 
resource access control, leveraging existing Web architecture.
>
> -- manu
>


-- 

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