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

[William Mills <[e-mail]>]

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,

-bill




>________________________________
> From: William Mills <[e-mail]>
>To: "[e-mail]" <[e-mail]> 
>Sent: Tuesday, April 3, 2012 5:10 PM
>Subject: [kitten] Feedback from IETF #83 on the OAUTH/SASL-KRB draft
> 
>
>
>I went to IETF #83 specifically to get feedback (and I though a tentative decision) on the question of whether the SASL message format currently there which uses HTTP was a good idea or not.  I did get a ton of good feedback in individual conversations, the conversation in the working group itself was a little less lively.
>
>From the WG meeting:
>-    several folks promised to read deeper and bring comments back to the list.
>-    Hannes' comment at the mic (my summary) was that given the many successful integrations against Google's XOAUTH that staying close to those has great value for getting successful uptake, and that adapting the code those clients use to new endpoints 
>
>From general feedback from random folks:
>-    Many folks said HTTP is in fact very hard to parse correctly if you have to parse it fully.
>-    Some folks felt existing implementations close to a proposed spec are likely to add to successful adoption.
>-    a few folks felt that it's reasonable to limit the stuff that actually has to be parsed.
>
>There are real difference between the complextity needed for XOAUTH and for the proposed OAUTH mechanism.  XOAUTH does everything in the URL, where the OAUTH proposal  I'll post here the Google XOAUTH SASL message format, and an example form the draft spec:
>
>From http://sites.google.com/site/oauthgoog/Home/oauthimap for XOAUTH:
>
>For example, before base64-encoding, the initial client request might look like this (with linebreaks added for clarity):
>
>(2-legged OAuth)
>GET https://mail.google.com/mail/b/[e-mail]/imap/?xoauth_requestor_id=someuser%40example.com
>    oauth_consumer_key="example.com",
>    oauth_nonce="4710307327925439451",
>    oauth_signature="75%2BB63NbW2GdDMaOCEd%2Fy%2Fb%2B0Qk%3D",
>    oauth_signature_method="HMAC-SHA1",
>    oauth_timestamp="1260933683",
>    oauth_version="1.0"
>
>
>
>For the OAUTH mechanism a similar style signed request example is:
>GET / HTTP/1.1
>Host: server.example.com
>User: [e-mail]
>Authorization: MAC token="h480djs93hd8",timestamp="137131200", nonce="dj83hs9s",signature="YTVjyNSujYs1WsDurFnvFi4JK6o="
>
>
>The OAUTH mechanism will require (as currently specified) parsing of a Host, User, and Authorization header.  The path and query is actually ignored at present.  Based on this message I'll be posing questions to the list.
>
>Regards,
>
>-bill  
>_______________________________________________
>Kitten mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/kitten
>
>
>