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

William Mills <> Mon, 04 February 2013 22:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4E82C21F8B35 for <>; Mon, 4 Feb 2013 14:30:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.762
X-Spam-Status: No, score=-1.762 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OmAawFwXqLpP for <>; Mon, 4 Feb 2013 14:30:01 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id EABCF21F8B2E for <>; Mon, 4 Feb 2013 14:29:58 -0800 (PST)
Received: from [] by with NNFMP; 04 Feb 2013 22:29:58 -0000
Received: from [] by with NNFMP; 04 Feb 2013 22:29:58 -0000
Received: from [] by with NNFMP; 04 Feb 2013 22:29:58 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 95022 invoked by uid 60001); 4 Feb 2013 22:29:57 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1360016997; bh=KbKXnLx6fTeG7EGQ54HosFPnzKmwgRbOLGlmAk8Dc4I=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=HtA0Ta6z1Ct2dO/ndE0MCoJnLC0rzJjH3wCdRLOqMlDyVjPAnZMAN2VPvYs43O40ZXmuDjsnoc0+T8qpHdd9g0JM70aCL3Ta0jdXmmenM0oUPPNA4OnnovY4bHleEhUxSWxj6nzun3jVv8JwFhP3yVtyA3yd8ndMWUa4j/l3jkw=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=YWvcggdSrHNiN0l2XJeC8d5ib5XlXtk4RXbr+gezVuJVmuyPaaP2tD0afIUuICzJ6q+LjA4wMhQ429RgdzFXhPQaD5YR0QY44ALxdhnuFq3MqjEPIIVmZtVO/rusDgXnDUqIcpNAKQX7HBMdEytkqR1l9dsAOWzRsqUeVnUNQt4=;
X-YMail-OSG: c3P0xcsVM1l.1hwKrL2aUyL14MMB_Pk1.ZP.wd6bNTlupaM WfQGQ0nXNuou2jIoFzw2nxrf1FaBAps5BlJwlSsKbqaIyy0lOIlUAnZZuFWH LNjcgTCK_L8QTcHM0JqKOrbmIuvCNAwAmjbacPABpg8_GUS04T2kZzBe95Il yCjAxZw.GlLP_2Ld3bGY5xC2ut645BHBK6DBXTRDoTPsNiBJMQCuialO5wTz rnjVCvZ5Hmgnp8HcG4yP_gsQSM2_xm_GZCHR6HiDOL2fQdGXCBubTDL7nf4F fKTpjQDH6L9zO1TztV2PLX9CiHBDCN2qfpF7wLg3Of1L5UqY3nogMygeM85Q 90nnIvh8UzqDS2i_qAoE98GLyOIDBMlXostBemDwVuEJ4QDgQ2e68YF0ZFpO BsXfwA3L75zniEO.5dMeqoeeAPBdkA4xPdfqELTNHHUNuZdUZGPeak2r297h GLxkXPNaZMR9Rn_2YyxZk1v1XXAES5n656YmBxj7n1rD9NZAKxWpI7O9NxN4 kj7Ub_fNFDlhRbz9Pb1Szn20Y8I_QltHYrA7TCD4cT68-
Received: from [] by via HTTP; Mon, 04 Feb 2013 14:29:56 PST
X-Rocket-MIMEInfo: 001.001, V2UgY2FuIGRvIHRoYXQgdG9vLCBhbmQgSSByYXRoZXIgbGlrZSBpdC4gwqBJIHRob3VnaHQgdGhlcmUgd2FzIGEgYmlnICJkb24ndCBjcm9zcyB0aGUgYmVhbXMiIHdhcm5pbmcgc29tZXdoZXJlIHRob3VnaC4KCi1iaWxsCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KIEZyb206ICJSaWNoZXIsIEp1c3RpbiBQLiIgPGpyaWNoZXJAbWl0cmUub3JnPgpUbzogV2lsbGlhbSBNaWxscyA8d21pbGxzXzkyMTA1QHlhaG9vLmNvbT4gCkNjOiBPIEF1dGggV0cgPG9hdXRoQGlldGYub3JnPiAKU2VudDoBMAEBAQE-
X-Mailer: YahooMailWebService/
References: <> <B33BFB58CCC8BE4998958016839DE27E068866EF@IMCMBX01.MITRE.ORG>
Message-ID: <>
Date: Mon, 04 Feb 2013 14:29:56 -0800
From: William Mills <>
To: "Richer, Justin P." <>
In-Reply-To: <B33BFB58CCC8BE4998958016839DE27E068866EF@IMCMBX01.MITRE.ORG>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1238014912-751286513-1360016996=:80104"
Cc: O Auth WG <>
Subject: Re: [OAUTH-WG] conf call follow up from today
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills <>
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Feb 2013 22:30:02 -0000

We can do that too, and I rather like it.  I thought there was a big "don't cross the beams" warning somewhere though.


 From: "Richer, Justin P." <>
To: William Mills <> 
Cc: O Auth WG <> 
Sent: Monday, February 4, 2013 1:37 PM
Subject: Re: [OAUTH-WG] conf call follow up from  today

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 <> 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.
>OAuth mailing list