HTTP Origin-Bound Authentication (HOBA)
draft-ietf-httpauth-hoba-10

Agree with Barry

Good stuff! Couple of comments.

= Logging out =

The intro says

"Logout features can be useful for UAs, so HOBA defines a way to
      close a current HTTP "session", and also a way to close all
      current sessions, even if more than one session is currently
      active from different UAs for the same account."
    
But the method specified in 6.3 seems to only accomplish the first of these (assuming the recommendation about server deletion of cookies related to "the session" is meant to be specific to one session). What is the method for logging out of all sessions associated with different UAs for the same account?

= Section 6.1 =

Either the device identifier/device identifier type bits are underspecified, or it's not clear to me how they are meant to be used. What other device identifier types are expected to be used in the future, such that a registry of them is necessary? To me it seems like you would want UAs/users to take some care with the precision of the device identifiers shared with servers -- e.g., "Alissa's laptop" seems like it could be useful and fairly safe, whereas "IMEI 013584009812219" seems like total overkill and a bad idea. (As an aside, it might be good to provide some guidance about this in the document.) The creation of the registry makes me wonder if more structured device identifiers of the IMEI-ilk are envisioned, and if so what the purpose of them is expected to be?

Also, I would suggest

s/if absent then the "string" form of device identifier MUST be used./if absent then the "string" form of device identifier defined in Section 9.5 MUST be used.

= Section 8 =

"Binding my CPK with someone else's account would be fun and
   profitable so SHOULD be appropriately hard."

Sarcasm translates pretty poorly across cultures. I would suggest saying what you actually mean here.

= Section 8.2 =

If you want to leave in the LinkedIn reference, or any specific example, it needs a citation.

satisfied with the rersults from david black's opsdir review.

Yay HOBA! Very good that we are finally doing this thing. Totally nitty things here. Barry covered anything substantive that I found:

- Use of the word "we" always makes me gag in IETF documents. Blech. For example, in 1.2 (2 times):

OLD
   We use this term when describing something that is
NEW
   This term is used when describing something that is

Passive voice is under-rated for some things. There are 9 other uses of "we" throughout the doc. We would be happy if we changed them.

- The last paragraph of section 2 is (a) ungrammatical and (b) seems more like it belongs in section 1.

- Grammatical 2119 fussiness:

OLD
   UAs MAY optimise their use of challenges by pre-fetching a challenge
NEW
   To optimise their use of challenges, UAs MAY pre-fetch a challenge

Old DISCUSS points:

(1) Cleared (I still think the architecture is bad and Stephen should feel bad, but I'm willing to let this go for Experimental)

(2) Cleared (SHA-1 only allowed if the platform doesn't do SHA-256)

(3) Cleared (bounds on <2048-bit keys)

-----

Given that the size of the header seems to be a concern (since you're not passing the key in the header), why are there no ECC signing algorithms defined?  It seems like if you used any of the normal curves, you could comfortably pass the key along with the authentication value.

The HOBA-TBS construction seems really unnecessarily complicated.  Other than in the "origin" component, there are no ":" characters allowed in any of the components, so if you could remove the unnecessarily pretty serialization of the origin, you could just use ':' as a delimiter.  Or leave the origin, and delimit with something like %x20.  Either way, this length construction seems like a pain to implement by comparison.

"alg = 1*2DIGIT" - In general, it seems unwise to limit code point spaces unnecessarily.

In addition to the funny title of Section 6.2.2, the contents seem kind of risible as well.  Making a OTP is 100% equivalent to the mechanism recommended in Section 6.2.3, and arguably more likely to deploy (since the OTP doesn't have special semantics of being a URI).

Please update the algorithms so that the reader doesn't have to go look up which algorithm this is (PKCS1 vs. PSS).

OLD: "RSA is defined in Section 8.2 of [RFC3447]" 

NEW: "RSA indicates the RSASSA-PKCS1-v1_5 defined in Section 8.2 of [RFC3447]"

Given how convoluted the use case is here, an example would be very helpful.  At the very least to demonstrate the syntax of the WWW-Authenticate header.