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

William Mills <> Mon, 04 February 2013 21:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EAFE621F8A77 for <>; Mon, 4 Feb 2013 13:33:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.484
X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id II1WYpxVep7l for <>; Mon, 4 Feb 2013 13:33:29 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 160FE21F892D for <>; Mon, 4 Feb 2013 13:33:29 -0800 (PST)
Received: from [] by with NNFMP; 04 Feb 2013 21:33:28 -0000
Received: from [] by with NNFMP; 04 Feb 2013 21:33:28 -0000
Received: from [] by with NNFMP; 04 Feb 2013 21:33:28 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 14853 invoked by uid 60001); 4 Feb 2013 21:33:28 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1360013608; bh=XzqYOrbWCLNbGdJjDJSINDOAJ9/7wLGCo7pns2IMbKA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=TN1EcFTyZnFx3ZFzxbniSSvcR8NaoXbCINLmokj4ABfBD9z7BeBTKjInfhDuzk0j1RVrna2L8q7DXfRzCBT/W0GOttVTvAUmtECTQHopr8Q7kbq5cgLLUBOJMyWVnOHbEOEE/qtrTQ6FWiQAWpaTYwCKQoUzYBIw/4fdcGlYeNM=
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:In-Reply-To:MIME-Version:Content-Type; b=nyEUO0sX2gWXHJNa1VPv6Khj7LextnGsrReD/NNViheNftYbClOJZvM9LOA9zrDCCLck6sGHuFxxr0lm9R+4vzJj6Z5OfPN07MwRr+3eRzE054qqzRWx5Gxbs89h8/ObRfF5xfol+kbNaaBK16I3pcJcMRh7yi/MLGVtLqtzJJs=;
X-YMail-OSG: 45wfy6sVM1mvZdgkG9O9mYGY88XZSEooD5VfigHqaDLB7yZ D69RtmWWuEsvu2X4YWNVnbJkto1O4ySHYpXEvaRUyawYDRcfpyLHgAU6Yf4J 6XScGJ1tjXeg4aHOgw7aDWkw7G8HTJ0h0vgAsiiZQecz8lLEMLhdpG.0l929 ZG0wItNmkn4ouT61eNHM239Jdc7Vi3VRDF7JCVyXpEHZwsWtYGIFpknrheti PrHPtMMVOz1o.VGQxvgsD1Uj6v2geNF.fibxhI7icqpy7HPBQnhq7Y5.lCR. PkSnLSFq5dPNf4NoaSy8K10v2ddUsvH8NleIzz49ax6PZN5qwjKhYFLxnoYX .9FNyhkGC7upNBY88YcGDc9RSlh_iTFXCe5qnSXd2ZJb1QP_unTUMaHInrLK fi5GmB_YivdKCS7WFwz_NUJmKmbj6oX5w0RUyALrDWqmVxSnrfSOxAYsJLxY XJyXNDBxjSmGityBg7Weho.ZaplZcodGEKmTcERgLq_ATqHB8tn3BdwFLIuV NUY10Ob5e2W4PJpRX2i6HHXwEr4Wh_.9XABzWjiyUUAs-
Received: from [] by via HTTP; Mon, 04 Feb 2013 13:33:27 PST
X-Rocket-MIMEInfo: 001.001, T0F1dGggMS4wYSBzb2x2ZXMgb3JkZXJpbmcgcHJvYmxlbXMgdGhlcmUgYnV0IG5vdCBhZGRpdGlvbmFsIGRhdGEgYmVpbmcgYWRkZWQgdG8gdGhlIHNwZWNpZmljIGhlYWRlcnMuIMKgSXQgc3BlY2lmaWNhbGx5IHJlcXVpcmVzIHRoZSBsaWJyYXJ5IHRvIGJyZWFrIGFwYXJ0LCBzb3J0LCBhbmQgcmVhc3NlbWJsZSBpbiBhIGFscGhhYmV0aWNhbCBvcmRlciBieSBuYW1lIHRoZSBxdWVyeSBzdHJpbmcgcGFyYW1ldGVycyBhbmQgb2F1dGhfKiBwYXJhbWV0ZXJzLiDCoE9uZSBvZiB0aGUgbGVzcyBwb3B1bGFyIHQBMAEBAQE-
X-Mailer: YahooMailWebService/
References: <> <>
Message-ID: <>
Date: Mon, 04 Feb 2013 13:33:27 -0800
From: William Mills <>
To: Prateek Mishra <>, "" <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-125733401-859990031-1360013607=:94969"
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 21:33:30 -0000

OAuth 1.0a solves ordering problems there but not additional data being added to the specific headers.  It specifically requires the library to break apart, sort, and reassemble in a alphabetical order by name the query string parameters and oauth_* parameters.  One of the less popular things about it. 

 From: Prateek Mishra <>
To:; William Mills <> 
Sent: Monday, February 4, 2013 1:28 PM
Subject: Re: [OAUTH-WG] conf call follow up from  today

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