W3C home > Mailing lists > Public > public-webpayments@w3.org > July 2014

Re: Browser integration. Re: HTTP Signatures draft published at IETF

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 29 Jul 2014 10:16:38 -0400
Message-ID: <53D7ACC6.5080409@digitalbazaar.com>
To: public-webpayments@w3.org
On 07/29/2014 01:16 AM, Anders Rundgren wrote:
> The draft talks about client authentication. IMO, that (usually)
> means using the browser.

>From RFC7230, http://tools.ietf.org/html/rfc7230#section-2.1 :

"An HTTP 'client' is a program that establishes a connection to a server
for the purpose of sending one or more HTTP requests."

Client means the software agent that is requesting the resource. Any
software that submits a GET/POST/DELETE/PATCH/etc. to a server is a
client. We're very careful to use the HTTP terminology correctly in this
spec.

Yes, browsers are clients, but so is any software that does an HTTP request.

> However, I don't see HTTP Signatures as a likely candidate for 
> integration in a browser, do you?

No, HTTP Signatures are probably not a likely candidate for integration
into the browser in the next 4 years. There is an argument that if the
login stuff we're working on ends up becoming popular, that there might
be a native integration story for the browsers. It's too early to
predict that sort of thing with any amount of accuracy, though.

The assumption is that HTTP Signatures will be used for
machine-to-machine communication between things like payment processors,
banks, and specific desktop/mobile software. The heaviest use will be in
non-browser scenarios and then potentially in Javascript shims/polyfills.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: High-Stakes Credentials and Web Login
http://manu.sporny.org/2014/identity-credentials/
Received on Tuesday, 29 July 2014 14:17:01 UTC

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