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

"Richer, Justin P." <jricher@mitre.org> Mon, 04 February 2013 21:37 UTC

Return-Path: <jricher@mitre.org>
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 7235C21F8456 for <oauth@ietfa.amsl.com>; Mon, 4 Feb 2013 13:37:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.565
X-Spam-Level:
X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.033, 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 BfnXmI5cHynB for <oauth@ietfa.amsl.com>; Mon, 4 Feb 2013 13:37:09 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E487D21F8B14 for <oauth@ietf.org>; Mon, 4 Feb 2013 13:37:08 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8440A531114A; Mon, 4 Feb 2013 16:37:08 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 748835311132; Mon, 4 Feb 2013 16:37:08 -0500 (EST)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0318.004; Mon, 4 Feb 2013 16:37:07 -0500
From: "Richer, Justin P." <jricher@mitre.org>
To: William Mills <wmills_92105@yahoo.com>
Thread-Topic: [OAUTH-WG] conf call follow up from today
Thread-Index: AQHOAx/HMw1LSuuzGkiPKErnOGKKJg==
Date: Mon, 4 Feb 2013 21:37:06 +0000
Message-ID: <B33BFB58CCC8BE4998958016839DE27E068866EF@IMCMBX01.MITRE.ORG>
References: <1360009331.12021.YahooMailNeo@web31801.mail.mud.yahoo.com>
In-Reply-To: <1360009331.12021.YahooMailNeo@web31801.mail.mud.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.48.118]
Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E068866EFIMCMBX01MITREOR_"
MIME-Version: 1.0
Cc: O Auth WG <oauth@ietf.org>
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:37:12 -0000

What if we define a means to request OAuth1 style tokens from an OAuth2 auth/token endpoint, but defer to OAuth1 for methods of how to use the token at protected resources?

 -- Justin

On Feb 4, 2013, at 3:22 PM, William Mills <wmills_92105@yahoo.com<mailto:wmills_92105@yahoo.com>> wrote:

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<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth