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

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

From: Henry Story <henry.story@bblfish.net>
Date: Mon, 22 Apr 2013 10:04:09 +0200
Cc: Kingsley Idehen <kidehen@openlinksw.com>, public-rww@w3.org, Web Payments <public-webpayments@w3.org>
Message-Id: <44509345-DDBC-45B5-8E54-5B9683A4D7FB@bblfish.net>
To: Manu Sporny <msporny@digitalbazaar.com>

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 

> 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 

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:


> 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 

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

Received on Monday, 22 April 2013 08:04:46 UTC

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