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

On 22 Apr 2013, at 04:38, Manu Sporny <msporny@digitalbazaar.com> 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.

That kind of thing would emerge out of http://www.w3.org/TR/WebCryptoAPI/
I suppose. 

> 2. No explanation of how to encrypt messages, deferring to TLS
>   instead (which may not always be available).

Same one would have to look to 
http://www.w3.org/TR/WebCryptoAPI/

> 3. No REQUIRED URLs for keys, making it non-trivial to figure out which
>   key signed a message.

We don't dissallow it either. So it's just a case of the need being felt.
If someone uses keys to sign then perhaps they should have

<sigDoc> signedWith <http://joe.me/profile#mykey>;
         signedBy  <http://joe.me/profile#me> .
         sigOf <doc> .



> 4. Expression of modulus and exponent in raw form, making it difficult
>   for developers to feed those values to common encryption libraries.

So writing a TLS implementation in JavaScript is not a problem but writing
a package that can do X509 parsing is a huge problem? We have implementations
of WebID in pretty much all languages, and parsing the cert was not the big 
issue. 

In any case you think using a PEM is cool, but then what about the PGP key,
or the new JSON key formats, etc. etc... 

> 5. Key registration is not covered in the specification.

Key Registration where? In an early mail I pointed out that we do have this:

https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/tls-respec.html#creating-a-certificate

> 6. Unnecessarily coupled with TLS client-cert protocol
>   (it's the only implementation of the protocol).

WebID-TLS is a protocol. 
There would be no trouble to have Persona-WebID, but they don't at present
want to put a URL in their JSON certificate.

> 7. Bad UX using client certs with browser makers not committed to making
>   the experience better.

They have been making it better. Chrome used to not have one, and
they now have persona type features.

> 8. No way to digitally sign HTTP requests.

Something to argue with the http://www.w3.org/TR/WebCryptoAPI/

> 9. Key generation and registration is left open-ended in the spec.

What would you improve in 
https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/tls-respec.html

> 
>> 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 try to keep things simple, and let protocols work together without
re-inventing anything if possible.

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

In another mail you just wrote

[[
Web Keys. Web Keys has nothing to do
with client-side certificates, nothing to do with local storage, nothing
to do with Flash, nothing to do with Web Sockets, and nothing to do with
browser-based website login.
]]

And yet you say it uses PEM encoded certificates and that it
is used for authentication. There is something I am failing to understand...

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

But they do authentication. What is it that WebKeys is doing now?

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

Social Web Architect
http://bblfish.net/