Subject: [http-auth] HOBA and draft-cavage signatures

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 May 2013 20:13:57 +0100

Hi,

So these two have a lot in common, but are in the end are a good
bit different I think. Sufficiently different that they probably
ought live separate lives as drafts probably, but maybe with bits
in common.

The common things:-

- HTTP Authentication schemes
- Both based on digital signatures for user authentication
- Similar or could-be-the-same syntax in lots of places
  which does offer the possibility of some library/code
  re-use that might help both

But there are very significant differences:

#1
- HOBA aims to displace passwords and no more
- draft-cavage wants to authenticate the user for payments as its
  main use-case

#2
= HOBA doesn't try to authenticate other parts of the HTTP request
  (we'll probably in -01 allow TLS channel bindings but that's not
  the same)
= draft-cavage does include other headers in the signature to
  authenticate those, possibly ultimately in a DKIM-like manner

#3
* HOBA has a key-pair-per-web-origin, at least as a default, with
  no HOBA-defined linkage between the public key and any identifier
  with well-defined semantics (applications can do that)
* draft-cavage I think wants just one or a few key pairs per user
  and probably with some well-defined semantics for identities
  associated with keys

#4
- HOBA has a built-in use of .well-known/hoba for registration
  etc.
- draft-cavage has very similar stuff in another spec but
  can't remember where that is:-)

Other notes:

- "Signature" as an HTTP authentication scheme seems way too
  broad - its hard to believe draft-cavage will be the only such
  ever (that's why I keep calling it draft-cavage above:-)
- I hate the idea that the same scheme supports both digital
  signatures and HMAC for user authentication - I think that's
  a bad error - just define two HTTP auth schemes if you really
  see a need for HMAC, or use the updated Digest that this WG
  is chartered to develop - encouraging more password verifier
  databases is just a bad plan (with all due respect to the
  other proposals this wg will develop:-)
- HOBA has this "demo of how to do hoba-js" aspect which isn't
  part of draft-cavage, us HOBA authors really like that:-)

Overall, I think (not very confidently, very much open to chatting
about it), were folks willing, it'd make sense to try define
common syntax and signature mechanism processing for these but
to progress them as separate HTTP authentication schemes that
both happen to use the digital signature mechanism but for
sufficiently different use-cases and security services that
they're better kept apart.

I'd be fine with this WG doing the work on draft-cavage if
that made sense. To get an HTTP authentication scheme
registered draft-cavage will have to pass IETF review in any
case, as that's the rule the httpbis WG have set for new
entries in that IANA registry. [1] So its not clear that
taking the W3C REC route will save the dravt-cavage
proponents much time, as their request for an IANA code
point will end up back here anyway. (Doing stuff in one
SDO is slow. Adding a 2nd SDO is a fine way to make
treacle look speedy:-)

But as I say, that's all fairly tentative so I wonder what
others think.

Cheers,
S.

[1] http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-22#section-2.3