Re: [kitten] OAUTH/SASL... to HTTP or not to HTTP, that is the question...

[William Mills <[e-mail]>]

One of the real takeaways for me from the IETF is that parsing HTTP is deep deep water with sharks in it.  Of the things we have to parse right now the hairiest would be the authorization header because it may have multiple authorization elements.  Everything else is comparatively simple.

The data elements we need are:
-    Host
-    port
-    Authorization header payload for the oauth profile
-    username -- used for auth(zn) endpoint discovery only
-    path+query string -- currently a stub of extensibility
-    HTTP body-- currently a stub of extensibility

The auth header payload is still going to have to be parsed by the server as is I think.  It's too complex to try to provide an arbitrary structured mapping for all cases and it's just an opportunity for error.

Extensibility can be done with an IANA registry of n/v fields for the purpose.  After that I'd probably choose a format like'Name ":" value CRLF' over JSON.




>________________________________
> From: Simon Josefsson <[e-mail]>
>To: William Mills <[e-mail]> 
>Cc: "[e-mail]" <[e-mail]> 
>Sent: Wednesday, April 4, 2012 12:47 AM
>Subject: Re: OAUTH/SASL...  to HTTP or not to HTTP, that is the question...
> 
>William Mills <[e-mail]> writes:
>
>> The major question remaining for my draft is HTTP(like) or not for the
>> SASL message format?  Please select one of the following:
>>
>>
>> A)    The current message format is fine.
>> B)    HTTP-like is OK as long as we limit the insanity.
>> C)    HTTP in any form is a deal breaker for me.  Give me something simple.
>> D)    None of the above, and I have a possible solution of my own to propose.
>>
>> For B above it's likely that we'd say something like "The server MUST
>> parse the Host, User, and Authorization headers and the server MAY
>> discard anything else.  The client MUST NOT use any HTTP extensions
>> such as compression and pipelining, and SHOULD NOT use line
>> continuations."
>>
>> Thanks in advance for the input,
>
>To get informed answers, I think we need to understand the implications
>of each answer.  Let's say we invent a new format for SASL OAUTH.  How
>much of a problem would that really be?  Where would the complexity
>related to HTTP have to be implemented?  Is it the server that would
>need to parse HTTP and transform it to something simpler?  Is the client
>completely shielded?
>
>Looking at history, I believe one of the main reasons DIGEST-MD5 didn't
>quickly replace CRAM-MD5 was that DIGEST-MD5 was so complicated to
>implement interoperable, and that was primarily because it re-used HTTP
>syntax.  So I don't think this is just a pet issue, it seems that if
>SASL wire syntax is too complicated, things won't get implemented.
>
>If I were to express a preference now I would lean towards B).  However,
>if the implications of C) are not severe, I think it would make sense to
>use a simpler format.  Then it becomes much easier to implement and
>analyse what goes on over the SASL wire.  Without a good rationale, I
>would be strongly opposed to free-form HTTP as the SASL syntax.
>
>/Simon
>
>
>