[whatwg] fixing the authentication problem
Tab Atkins Jr.
jackalmage at gmail.com
Tue Oct 21 07:43:38 PDT 2008
On Tue, Oct 21, 2008 at 9:36 AM, Eduard Pascual <herenvardo at gmail.com>wrote:
> On Tue, Oct 21, 2008 at 2:16 PM, Aaron Swartz <me at aaronsw.com> wrote:
> > My proposal: add something to HTML5 so that the transaction looks like
> this:
> >
> > Client: GET /login
> > Server: <html><form method="post" pubkey="/pubkey.key">...
> > Client: POST /login
> > dXNlcj1qb2VzbWl0aDAxJnBhc3N3b3JkPXNlY3JldA==
> > Server: 200 OK
> > Set-Cookie: acct=joesmith01,2008-10-21,sj89d89asd89s8d
> >
> > where the base64 string is the form data encrypted with the key
> > downloaded from /pubkey.key. This should be fairly easy to implement
> > (for clients and servers), falls back to exactly the current behavior
> > on browsers that don't support it, and solves a rather important
> > problem on the Web.
> What's the actual difference between this and https? Both mechanisms
> are using public-key encryption to protect the communications; the
> only difference being that with https the encryption is handled at the
> protocol level; while your suggestion would (currently) require to
> reinvent the wheel, encrypting the data on the client (maybe using
> JavaScript?) and then decripting it on the server (probably via
> server-side scripting).
> Maybe there is a good point on that suggestion, and I'm simply failing
> to see it. If that's the case, I invite you to enlighten me on it.
>
I agree in general with the criticisms raised here, but I'll correct a small
point in your post. The goal for this is to *not* require authors to do any
client-side encrypting, but for the UAs to encrypt instead. It would then
be the responsibility of the author to decrypt on the server side.
~TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081021/1e85a47f/attachment.htm>
More information about the whatwg
mailing list