Re: [apps-discuss] [http-auth] Web Keys and HTTP Signatures

Stephen Farrell <> Fri, 19 April 2013 10:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3FF4B21F9305; Fri, 19 Apr 2013 03:58:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d6jXXMTEmCnh; Fri, 19 Apr 2013 03:58:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 93D3D21F8F28; Fri, 19 Apr 2013 03:58:28 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 16AABBE70; Fri, 19 Apr 2013 11:58:05 +0100 (IST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d6fUiIlILzr9; Fri, 19 Apr 2013 11:58:05 +0100 (IST)
Received: from [IPv6:2001:770:10:203:b90d:e185:2958:9b0] (unknown [IPv6:2001:770:10:203:b90d:e185:2958:9b0]) by (Postfix) with ESMTPSA id DAE5CBE6E; Fri, 19 Apr 2013 11:58:04 +0100 (IST)
Message-ID: <>
Date: Fri, 19 Apr 2013 11:58:05 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: Manu Sporny <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: IETF HTTP Auth <>, Web Payments CG <>, IETF Apps Discuss <>
Subject: Re: [apps-discuss] [http-auth] Web Keys and HTTP Signatures
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Apr 2013 10:58:30 -0000

Hi Manu,

Just on the HOBA bit...

On 04/18/2013 10:27 PM, Manu Sporny wrote:
> HTTP Origin-Bound Authentication (HOBA)
> We had considered signatures in the URL in the second approach to the
> problem in the Web Keys spec. We eventually rejected the solution
> because of limitations in the URL length in some browsers and because we
> wanted the semantics of the HTTP headers to be able to be a part of the
> digital signature. We also didn't want large signed messages being
> dumped to the webserver logs (the request line is typically included).
> So, while HOBA does solve the problem, it doesn't solve it in a way that
> is acceptable to us.

I think you're misreading the spec a little, or we've written
it badly:-)

The HTTP scheme in HOBA is an HTTP authentication scheme so I
don't know what you mean when you say putting the signatures
in the URLs, since we don't do that. I think its that part
(section 4 of the HOBA draft) where there's most in common
between these, but also section 6.

The non-normative JS stuff does say to put the signature in
the URL though yes, but is quite a work-in-progress. That
section is really there to demonstrate that a site could do
the moral equivalent of HOBA without waiting for all UAs
to implement the spec. so e.g., if forms made for a better
example that'd be ok too I think (not sure if my co-authors
agree though). But your points about message size and logs
are reasonable.

HOBA is just about public key methods, not HMAC which is
a real difference.

All in all your stuff and this looks quite similar to me, so
I'd say we should talk all right.