Skip to main content

HTTP Origin-Bound Authentication (HOBA)

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: RFC Editor <>,
    httpauth mailing list <>,
    httpauth chair <>
Subject: Document Action: 'HTTP Origin-Bound Authentication (HOBA)' to Experimental RFC (draft-ietf-httpauth-hoba-10.txt)

The IESG has approved the following document:
- 'HTTP Origin-Bound Authentication (HOBA)'
  (draft-ietf-httpauth-hoba-10.txt) as Experimental RFC

This document is the product of the Hypertext Transfer Protocol
Authentication Working Group.

The IESG contact persons are Kathleen Moriarty and Stephen Farrell.

A URL of this Internet Draft is:

Ballot Text

Technical Summary

   HTTP Origin-Bound Authentication (HOBA) is a digital signature based
   design for an HTTP authentication method.  The design can also be
   used in Javascript-based authentication embedded in HTML.  HOBA is an
   alternative to HTTP authentication schemes that require passwords and
   therefore avoids all problems related to passwords, such as leakage
   of server-side password databases.

Working Group Summary

   This document is one of the experimental documents submitted to the
   HTTP-Auth working group. The proposed authentication method has been
   reviewed by many participants, mostly in WGLC, resulting in a 
   longish list in the acknowledgements section and some substantial 
   With version -07 it is the consensus of the HTTP-Auth working group 
   that this document is fit to be published as an experimental RFC.

Document Quality

   There are at least two implementations of the protocol in this 
   document ([1],[2]). They work and interoperate, but there is no 
   wide-spread deployment, which suggests that "experimental" is the 
   correct track for this document.

   All authors have confirmed that they are not aware of any undisclosed 
   IPR associated with this document. There have been no IPR disclosures.



   Yoav Nir is the document shepherd.  Kathleen Moriarty is the
   responsible Area Directory. 

RFC Editor note: Change reference name [bland] to [examples] or
something similar so it is understood what is the intended use of the

I'm sure the author just put it there to make sure I checked ;-)

RFC Editor Note