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

Kathleen Moriarty <> Mon, 02 March 2015 16:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 479151A1AB5 for <>; Mon, 2 Mar 2015 08:08:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uVsGfYZvgA3e for <>; Mon, 2 Mar 2015 08:08:03 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 718871A0115 for <>; Mon, 2 Mar 2015 08:07:50 -0800 (PST)
Received: by labgd6 with SMTP id gd6so31353717lab.7 for <>; Mon, 02 Mar 2015 08:07:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OOirfmx06DBUuEpHz44D5udpGUXBufDp4jgYwgItUn8=; b=zuJaBDdEWM0s1xKty4i+MXTC+0ZIEp7rqpgAJigtT/8ZzI4j4RKa6Eq1oIDXYPC+II K8L/fumbj6ywfV1aktKhQeyHsVJkBAGp75vYfp8YREUzesx+XdUxdfJYF2zdZNRUJiza wVWgoujtinrlI9nOmwHeRHuEK/7IbN8nFrZMvkFWU1/EEPHdmFspf/s/cym7UuM9m8YB SQFg3lilbR3qhtZcoW1pnX5AhcVZgS5UueiGdzPawbCYltWFvlxULBJ8X+14Azufgknp ioTyHSfaPR/sm5qOX8uWjfwFjyzTDcKLFsR7qFouGMceeskz2L9ZwB8hw09bOCnV/EPI ybiA==
MIME-Version: 1.0
X-Received: by with SMTP id ay6mr24430883lab.75.1425312468876; Mon, 02 Mar 2015 08:07:48 -0800 (PST)
Received: by with HTTP; Mon, 2 Mar 2015 08:07:48 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Mon, 02 Mar 2015 11:07:48 -0500
Message-ID: <>
From: Kathleen Moriarty <>
To: Justin Richer <>
Content-Type: multipart/alternative; boundary="001a11c25e5466c11f0510506b88"
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: Mon, 02 Mar 2015 16:08:06 -0000


I'd like to see if we can get last call started on this one soon.

My questions are not all specific to this draft and I won't hold up this
draft for answers that are broader.

For this one, if the duplicate TLS text can be addressed, that would be

Then, I'll also need to know more on my questions from the shepherd report
in my initial message.  I think this should be easy to resolve so we can
progress the draft.


On Thu, Feb 26, 2015 at 11:54 AM, Kathleen Moriarty <> wrote:

> Hi Justin,
> Thanks for the quick response.
> On Thu, Feb 26, 2015 at 11:40 AM, Justin Richer <> wrote:
>> 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. :)
> Thanks for playing with this, it might help.
>> 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
> Yes, I realized that when I read it, thanks.
>> 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?
> I brought this up as I read a few drafts for last week's telechat, one was
> the BCP for TLS.  As a result, it got me digging into a few drafts to see
> how it is getting used.  Hence, me noticing this possible issue in this
> review.
> The TLS protocol itself defines a large number of cipher suites for use
> that are registered with IANA (defined per version, but you have to dig
> into the referenced specs to see when each was added).
> Then a number of protocols that use TLS define an MTI to ensure interop
> between implementations, but typically have an explicit statement to allow
> for algorithm agility.  The recent drafts seem to select one of the
> recommended cipher suites from the list int he new TLS BCP.
> Does use of TLS show up in an earlier draft or published OAuth RFC where
> this would be appropriate to define?  How do implementations ensure interop
> now? Maybe that will help answer this question.
>> 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
> --
> Best regards,
> Kathleen


Best regards,