W3C home > Mailing lists > Public > public-identity@w3.org > March 2012

Re: Beyond HTTP Authentication: OAuth, OpenID, and BrowserID: Meeting on March 29th at IETF83

From: Anders Rundgren <anders.rundgren@telia.com>
Date: Wed, 21 Mar 2012 21:04:08 +0100
Message-ID: <4F6A3438.90903@telia.com>
To: Henry Story <henry.story@bblfish.net>
CC: Francisco Corella <fcorella@pomcor.com>, Harry Halpin <hhalpin@w3.org>, "public-identity@w3.org" <public-identity@w3.org>, Karen Lewison <kplewison@pomcor.com>
On 2012-03-21 17:25, Henry Story wrote:
> Btw. Certificates and a JS Crypto api should work very well together.
> You would just get the best of both worlds. It is odd to try to make
> syntactic distinctions between certificate formats and have JS APIs
> be sensitive to those. To do so can only be a political decision, and
> engineering based on that can only lead to laughable results.

If you are referring to DOMCrypt I don't agree because DOMCrypt [AFAIK] builds
on domain-bound keys which doesn't translate to certificates unless these
also are domain-bound.   Domain-bound certificates would be a crummy concept
since the public key should be known by the RP in most DOMCrypt scenarios.

Mozilla's crypto.signText () is IMO a better JS+X.509 fit than DOMCrypt.
They build on quite different principles.


> Anyway I also happen to live close to Paris. If you want I could present WebID 
> quickly and show how these fit together. I argued for it here
> http://security.stackexchange.com/questions/5406/what-are-the-main-advantages-and-disadvantages-of-webid-compared-to-browserid
> but there are many aspects to it. A face to face can't harm. 
> Henry
> On 21 Mar 2012, at 17:12, Francisco Corella wrote:
>> Harry,
>> > > This thread shows that a workshop on user certificates would be
>> > > useful.  Are you still planning on having one this spring, or have
>> > > you given up on that?
>> >
>> > We'll see. It depends on how the Web Crypto WG goes, some amount
>> > (although not everything talked about on this mailing list)
>> > certificate handling is in "secondary features" so I see no real
>> > reason for another workshop at this point unless it seems another WG
>> > is necessary to do that work.
>> The Web Crypto WG is about a JavaScript API.  Issuing and using
>> certificates should not require JavaScript.  TLS client certificates
>> are not a JavaScript feature.  The <keygen> element, a building block
>> for certificate issuance, is not a JavaScript feature.  It is possible
>> today to issue a certificate automatically to at least one browser
>> (Firefox) without JavaScript, although not securely.
>> A workshop would help you decide whether a WG is needed; and it would
>> be useful to get the people interested in certificates in one room,
>> whether or not a WG follows.
>> Francisco
> Social Web Architect
> http://bblfish.net/
Received on Wednesday, 21 March 2012 20:04:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:00:48 UTC