Re: [http-auth] Last Call: <draft-ietf-httpauth-hoba-07.txt> (HTTP Origin-Bound Authentication (HOBA)) to Experimental RFC

[Julian Reschke <[e-mail]>]

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"?

>>     ...
>>
>>     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.

> ...
>>     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 :-)

> ...
>> 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, 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.

> ...
>> 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...

Best regards, Julian