Re: [OAUTH-WG] AD review of draft-ietf-oauth-dyn-reg-management

Justin Richer <> Thu, 26 February 2015 16:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7EF041A1BB9 for <>; Thu, 26 Feb 2015 08:40:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IM0-GDp28zP9 for <>; Thu, 26 Feb 2015 08:40:36 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 928BB1A0218 for <>; Thu, 26 Feb 2015 08:40:36 -0800 (PST)
X-AuditID: 1209190e-f79bb6d0000030e8-fa-54ef4c823807
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id A3.B0.12520.38C4FE45; Thu, 26 Feb 2015 11:40:35 -0500 (EST)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t1QGeYPn024769; Thu, 26 Feb 2015 11:40:34 -0500
Received: from artemisia.richer.local ( []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id t1QGeVQH018445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Feb 2015 11:40:33 -0500
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_736388E3-3177-4937-B63F-47F24D740F65"; protocol="application/pgp-signature"; micalg=pgp-sha1
X-Pgp-Agent: GPGMail 2.5b5
From: Justin Richer <>
In-Reply-To: <>
Date: Thu, 26 Feb 2015 11:40:30 -0500
Message-Id: <>
References: <>
To: Kathleen Moriarty <>
X-Mailer: Apple Mail (2.2070.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMKsWRmVeSWpSXmKPExsUixG6nrtvs8z7E4NMdDouGnfkWJ9++YnNg 8tg56y67x5IlP5kCmKK4bFJSczLLUov07RK4MqbdNi747loxe8Ua1gbGazZdjJwcEgImEg0T rrND2GISF+6tZ+ti5OIQEljMJPHrZCsrhLORUWL79jssEM5DJombyw6zgbQIC3hILH51hgnE 5hUwkJh76gsTSBGzwCRGiWOzZrFAzJWSeHB7DSOIzSagKjF9TQtYA6dAoMTW9evBbBag+NqJ h4HWcQA1q0u0n3SBmGkl8e7FRbBWIYEAiR8314LZIgIWEmuav7GBlEsIyEv0bEqfwCg4C8kV s5BdAZJgFkiSuP+4gQnC1pZYtvA1M4StKbG/ezkLpriGROe3iawQtrzE9rdzoOKWEotn3oCq t5W41bcAaqadxKNpi1gXMHKvYpRNya3SzU3MzClOTdYtTk7My0st0jXWy80s0UtNKd3ECIo/ Tkm+HYxfDyodYhTgYFTi4d2R+y5EiDWxrLgy9xCjJAeTkiivrtf7ECG+pPyUyozE4oz4otKc 1OJDjCpAux5tWH2BUYolLz8vVUmEV98aqI43JbGyKrUoH6ZMmoNFSZx30w++ECGB9MSS1OzU 1ILUIpisDAeHkgRvrDdQo2BRanpqRVpmTglCmomD8xCjBAcP0HA2kBre4oLE3OLMdIj8KUZF KXHedyDXCYAkMkrz4HphafMVozjQW8K8SiDtPMCUC9f9CmgwE9DgA3ffgQwuSURISTUwMulM NK85Ojek3I/hzHz9RYf1301n2Zj++FjZ7FqOjZOEDnTqndd7n8Z26NPzpdtsj+fMEXvVYHty t1Dur1+f6u1u2OfnpfxnjlwX1u7b8WCFAPOnv6efM010uZBnX+WodcfURt5f45vvXIapq11/ 1MtJ/p15YE/7Wjvrhh0b1LWZ7Hf9/ftYX4mlOCPRUIu5qDgRAMxfGCJ2AwAA
Archived-At: <>
Cc: "<>" <>
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-dyn-reg-management
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Feb 2015 16:40:39 -0000

On Feb 26, 2015, at 11:04 AM, Kathleen Moriarty <> wrote:
> Hello,
> I reviewed draft-ietf-oauth-dyn-reg-management, which reads well and I just have a few questions and suggestions below that would be good to address prior to IETF last call.
> Section 1.3
> Bullet D might be easier to read as a list within the bullet.

OK, I’ll try that and see how it renders in the various output formats. Lists-within-lists don’t always play nice in my experience, hence the paragraph format, but we’ll see what it looks like. I agree that it’s an intimidating block of information there. :)

> Section 2
> This is something I don't recall offhand and may be in place in another draft, so a pointer would be great.  Is there an MTI set for one of the recommended cipher suites in the TLS & DTLS BCP to ensure interoperability (but also allow for algorithm agility)?  If not and there is a reason, please explain.
> See section 4: <>
> This is not the right draft to add this content, but I'd like to know if it is covered somewhere or doesn't need to be for some reason.  TLS requirements should point to that draft (assuming one exists) so there is only one place to update if needed for any specific requirements to OAuth.

This is a copy of the text found in

We basically just want to say “use an encrypted channel” and point to the best guidance there is out there at the time. There shouldn’t be any specific requirements for OAuth. Maybe in the future the IETF could have a standard single reference for transport protection that can be included a-la the 2119 definitions?

> IANA Considerations:
> The shepherd report says that there are no actions for IANA, so this needs to be updated as the draft is the specification required to add two new entries to an existing registry, established by the parent document.  It does require DE review on the mailing list: <>
> If that has been done, then a pointer to the archive would be helpful.
> Thank you.
> --
> Best regards,
> Kathleen

Thanks for the review,
 — Justin

> _______________________________________________
> OAuth mailing list