Re: [OAUTH-WG] conf call follow up from today

Prateek Mishra <prateek.mishra@oracle.com> Mon, 04 February 2013 21:28 UTC

Return-Path: <prateek.mishra@oracle.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6D121F8AF2 for <oauth@ietfa.amsl.com>; Mon, 4 Feb 2013 13:28:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqsAsHduMdRe for <oauth@ietfa.amsl.com>; Mon, 4 Feb 2013 13:28:21 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5A421F8AE7 for <oauth@ietf.org>; Mon, 4 Feb 2013 13:28:21 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r14LSKsn015227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Feb 2013 21:28:21 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r14LSJFH028785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2013 21:28:20 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r14LSJF3012069; Mon, 4 Feb 2013 15:28:19 -0600
Received: from [10.152.55.88] (/10.152.55.88) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Feb 2013 13:28:19 -0800
Message-ID: <511027F1.8050607@oracle.com>
Date: Mon, 04 Feb 2013 16:28:17 -0500
From: Prateek Mishra <prateek.mishra@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: oauth@ietf.org, William Mills <wmills_92105@yahoo.com>
References: <1360009331.12021.YahooMailNeo@web31801.mail.mud.yahoo.com>
In-Reply-To: <1360009331.12021.YahooMailNeo@web31801.mail.mud.yahoo.com>
Content-Type: multipart/alternative; boundary="------------060206080601040708070505"
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: Re: [OAUTH-WG] conf call follow up from today
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Feb 2013 21:28:22 -0000

Bill -

How does OAuth 1.0a deal with the problem of HTTP URL and header 
mutability? Header order may get re-arranged and URLs modified in 
transit from client to server. As a result, the signature/HMAC
might not validate at the final destination.

Isn't that a foundational problem with the OAuth 1.0a model? I thought 
that was one of the concerns expressed at the meeting today.

- prateek


> 1)  I think that we need to focus on specific solutions, as I said on 
> the call, and solve the OAuth 1.0a/MAC use case.  There's significant 
> installed base of OAuth 1.0a and we need a path for those 
> installations into OAuth 2.0.  I may well pursue MAC in the interim to 
> do this, but a full HOK solution woul work too.
>
> 2)  I think the discussion we were having about "which authenticator 
> to use" falls squarely into the endpoint discovery discussion and we 
> should put that energy into endpoint discovery as distinct from HOK.
>
> 3)  We haven't talked yet about how a client will be able to specify a 
> token type if it wants a specific one.  OAuth 2 core will need to be 
> extended to support this.
>
> 4)  We should leave the key distribution/discovery mechanism either 
> out of scope or define it explicitly per HOK token type profile.  This 
> will have to work with the extensions for #3 above.
>
> 5)  I want to avoid the problem in OAuth 1.0a of having to support and 
> accept every possible signing mode.  Being force to accept PLAINTEXT 
> sucks.  We need a way for the discovery endpoint to mandate a specific 
> set of allowed signature methods.
>
> Regards,
>
> -bill
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth