Hiya, Thanks for the follow up... On 24/12/14 11:40, Julian Reschke wrote: > On 2014-12-24 12:15, Stephen Farrell wrote: >> ... >>> 2. The HOBA Authentication Scheme >>> >>> HOBA-TBS = len ":" nonce >>> len ":" alg >>> len ":" origin >>> len ":" [ realm ] >>> len ":" kid >>> len ":" challenge >>> len = 1*DIGIT >>> nonce = 1*base64urlchars >>> alg = 1*2DIGIT >>> origin = scheme "://" authority ":" port >>> realm = unreserved >>> kid = 1*base64urlchars >>> challenge = 1*base64urlchars >>> ; Characters for Base64URL encoding from Table 2 of RFC 4648 >>> base64urlchars = %x30-39 ; Digits >>> / %x41-5A ; Uppercase letters >>> / %x61-7A ; Lowercase letters >>> / "-" / "_" / "=" ; Special characters >>> >>> Figure 1: To-be-signed data for HOBA >>> >>> ...specify a proper ABNF production for "unreserved". >> >> What? I don't know what you mean there. I added a pointer to >> 2.2 of RFC 7235 though, is that enough? > > What's the ABNF for "unreserved"? See p18 of RFC 3986. I (sadly) added yet another comment around the already overloaded abnf there. (Sadly, because I think we're now documenting this assuming all developers are dim, which if sad if correct, and sad if incorrect;-) > >>> ... >>> >>> The registration message for HOBA-http is sent as a POST message to >>> the URL ".well-known/hoba/register" with an HTML form (x-www-form- >>> encoded) described below; The registration message for HOBA-js >>> can be >>> >>> Need citation for payload format. >> >> To RFC 1867? Added that (though it's been obsoleted). Happy to >> replace with a better ref so long as that better ref is not a >> work-in-progress:-) > > <http://www.w3.org/TR/2014/REC-html5-20141028/forms.html#url-encoded-form-data> > I assume. Lovely. > >> ... >>> when the registration has succeded to indicate the new state. The >>> header to be used is "Hobareg" and the value when registration has >>> succeeded is to be "regok". When registration is inwork (e.g. on an >>> HTTP response for an interstitial page) the server MAY add this >>> header with a value of "reginwork". See Section 9.6 for the >>> relevant >>> IANA registration of this header field. >>> >>> Could this use the Authentication-Info header field currently defined in >>> DIGEST? >> >> Maybe but would prefer to not entwine with DIGEST in that way. >> Seems like all we'd get is delay and no benefit. > > ...that supports my p.o.v. that it should be in a separate spec :-) Sure. And when it is and if HOBA is put on the standards-track those can be better aligned if that's seen as useful. > >> ... >>> 6.3. Logging Out >>> >>> >>> The user can tell the server it wishes to log out. With HOBA-http, >>> this is done by sending any HOBA-authenticated HTTP message to the >>> URL ".well-known/hoba/logout" on the site in question. The UA >>> SHOULD >>> also delete session cookies associated with the session so that the >>> user's state is no longer "logged in." >>> >>> Nope. Don't define this for GET (or any "safe" method). POST would work. >> >> Sorry I'm not seeing why that is GET specific? I agree POST should be >> fine too, but think that is allowed by the above. > > GET is defined as safe, Ah sorry, I mis-read your comment. You're right. Luckily, that's what the code I've seen does anyway:-) But that's a good catch. > and safe is defined as: > > "Request methods are considered "safe" if their defined semantics are > essentially read-only; i.e., the client does not request, and does not > expect, any state change on the origin server as a result of applying a > safe method to a target resource. Likewise, reasonable use of a safe > method is not expected to cause any harm, loss of property, or unusual > burden on the origin server." -- > <http://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7231.html#rfc.section.4.2.1.p.1> > > > So you can't have GET perform a logout. Changed that to say use POST. > >> ... >>> Appendix B. Example >>> >>> >>> The following values show an example of HOBA-http authentication to >>> the origin https://example.com:443 Carriage-returns have been added >>> >>> s/443/443./ >> >> Sure, though not sure what RFC editor prefers there (for URLs at >> the end of sentences) but they can fix if needed. > > In doubt, put it the URI in delimiters... Or... If in doubt, wait and see what RFC editor prefers:-) The above changes applied as before at [1,2]. If there's no more follow up, I'll publish that in a couple of days. Cheers, S. [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-08.txt [2] https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-07.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-08.txt > > Best regards, Julian