[kitten] Feedback from IETF #83 on the OAUTH/SASL-KRB draft

[William Mills <[e-mail]>]

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