Re: [OAUTH-WG] LC Review of draft-ietf-oauth-dyn-reg-12
Justin Richer <jricher@mitre.org> Tue, 04 June 2013 19:57 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 755D821F93D2 for <oauth@ietfa.amsl.com>; Tue, 4 Jun 2013 12:57:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.188
X-Spam-Level:
X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AgZ51-ZjY16 for <oauth@ietfa.amsl.com>; Tue, 4 Jun 2013 12:57:16 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D88DE21F9A97 for <oauth@ietf.org>; Tue, 4 Jun 2013 11:57:32 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BB1591F02A9; Tue, 4 Jun 2013 14:57:28 -0400 (EDT)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id AAF4B1F029C; Tue, 4 Jun 2013 14:57:28 -0400 (EDT)
Received: from [10.146.15.13] (129.83.31.56) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 4 Jun 2013 14:57:28 -0400
Message-ID: <51AE386A.2090308@mitre.org>
Date: Tue, 04 Jun 2013 14:56:42 -0400
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: Phil Hunt <phil.hunt@oracle.com>
References: <CDD3A32C.8B9D%aanganes@mitre.org> <1BF3B6CF-9CFC-4C91-A066-98871271FFF4@oracle.com>
In-Reply-To: <1BF3B6CF-9CFC-4C91-A066-98871271FFF4@oracle.com>
Content-Type: multipart/alternative; boundary="------------030105020307070907080802"
X-Originating-IP: [129.83.31.56]
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] LC Review of draft-ietf-oauth-dyn-reg-12
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: Tue, 04 Jun 2013 19:57:21 -0000
That's correct, but they're all editorial (non-normative) in nature and I've been in communication with the other editors as well. Everyone is welcome to follow along with the editing process in github if they like. -- Justin On 06/04/2013 02:43 PM, Phil Hunt wrote: > Those changes off git hub have not been shared with the group and are > not necessarily approved. > > Phil > > On 2013-06-04, at 11:03, "Anganes, Amanda L" <aanganes@mitre.org > <mailto:aanganes@mitre.org>> wrote: > >> Note that this review applies to the latest spec edits from Justin's >> Github, which can be found here: >> https://github.com/jricher/oauth-spec. The --12 revision has not been >> published yet, but Justin asked me to review based off of what was in >> the tracker, since it is more up-to-date. >> >> --Amanda >> >> From: <Anganes>, "Anganes, Amanda L" <aanganes@mitre.org >> <mailto:aanganes@mitre.org>> >> Date: Tuesday, June 4, 2013 1:56 PM >> To: "oauth@ietf.org <mailto:oauth@ietf.org>" <oauth@ietf.org >> <mailto:oauth@ietf.org>> >> Subject: LC Review of draft-ietf-oauth-dyn-reg-12 >> >> [[Apologies if you receive this twice, I accidentally sent this from >> one of my other email addresses this morning (Outlook seems to have >> been confused).]] >> >> Hello, >> >> I have reviewed the Dynamic Registration draft and offer some >> comments below: >> >> After section 1.2, I suggest adding a flow diagram (similar to those >> in the core OAuth 2.0 spec), showing the interaction of the >> client/developer with the respective endpoints, and the requests and >> responses involved. I think this will make the spec easier to read. >> >> Inside the 3rd paragraph of section 1.3, there is text buried that >> talks about client credential rotation (client_secret and >> Registration Access Token). I think this notion of secret rotation >> should be called out in its own paragraph or subsection and labeled >> as such. Suggested text (I'm not sure where it should go): >> >> Section X.X Client Credential Rotation >> >> The Authorization Server may rotate the Client's issued >> client_secret and/or Registration Access Token. The client_secret >> MAY be rotated at any time, in which case the Client will likely >> discover that their secret has expired via attempting and failing >> to make a request. The Registration Access Token SHOULD only be >> rotated in response to an update or read request, in which case >> the new Registration Access Token will be returned in the >> response back to the Client. The Client can check their current >> credentials at any time by performing a READ or UPDATE operation >> at the Client Configuration Endpoint. >> >> >> Section 3 Client Registration Endpoint >> >> This section should use the phrase "this endpoint may be open, or >> it may be an OAuth 2.0 Protected Resource", rather than just >> stating that it may accept an initial token. I *think* that the >> choice is an either/or for a given server (ie, a server cannot >> offer both open and protected registration), but that should be >> clarified as well. >> >> In the 4th paragraph, the final sentence ("As such, the Client >> Configuration Endpoint MUST...") refers to the Configuration >> endpoint, not the Registration endpoint. The text is already in >> Section 4 so it should just be deleted here. >> >> Section 3.1 Client Registration Request >> >> >> The lead-ups to the two example requests are phrased oddly. The >> difference between the two sample requests is not whether the >> client has a token, it's whether the endpoint is open or >> protected. Suggest changing them to "For example, if the Client >> Registration Endpoint supports open registration, the client >> could send the following request" and "Alternatively, if the >> endpoint is an OAuth 2.0 protected resource, the client MUST >> include an OAuth 2.0 Access Token/the Initial Access Token in its >> request, presented as a Bearer token using the Authorization >> header according to RFC6749." (My phrasing at the end regarding >> how to present the AT may be off; point is that it should be >> called out.) >> >> >> Nits in section 7 Security Considerations: >> >> 2nd paragraph, first sentence: "...requests to the >> *Client* Registration Endpoint" >> >> 6th paragraph, first sentence: "...the Registration Access Token >> should not expire..." I think this should be a SHOULD NOT? >> Same paragraph, 4th sentence has a non-capitolized "client" that >> should be "Client" (although, after reading Hannes' review, maybe >> the capitalized instances should all be lowercased instead). >> >> >> I also second Hannes' comment that the RFC 2119 language feels off >> throughout the spec, suggest doing a careful read to check those. >> >> Finally, to address the Initial Access Token / Registration Access >> Token discussion that has been ongoing: >> >> My initial response after reading this draft (and having followed the >> discussion) was to say, remove the "Initial Access Token" term >> completely and instead just clarify the text to say that "the Client >> Registration Endpoint MAY be an OAuth 2.0 protected resource, but the >> details of how a given client or developer goes about acquiring an >> Access Token for use at this endpoint is out-of-scope". I spoke to >> Justin about this and he pointed out that this term was only added >> recently, and it was added because of confusion around how the Client >> Registration Endpoint was defined, and what it means to authenticate >> to it. I don't think the new name/definition/explanation has helped; >> but the previous drafts were also missing the "OAuth 2.0 protected >> resource" language. To be clear, I think this functionality is >> absolutely necessary, but we need to clarify its explanation >> >> On the other hand, the Registration Access Token seems very clear to >> me. I think that term should be called out as a named entity, since >> it is 'special' - it's not issued by a token endpoint, but by the >> Client Registration Endpoint. >> >> I see a few options that might help: >> >> 1) Perhaps "Initial Access Token" is a bad name. Unfortunately, I >> think the right names are "Registration Access Token" for >> accessing the Registration Endpoint, and "Configuration Access >> Token" for accessing the Configuration Endpoint. This would >> require changing code, since the configuration token is returned >> in the Client Registration Response. >> >> >> 1.a) The examples in Appendix B only use the IAT for >> Developer authentication/tracking (all clients registered >> using the same IAT can be traced to the developer that was >> issued that particular token). Is that the only use case? If >> there is always a developer in the loop in the protected >> case, then "Developer Access Token" might be appropriate. >> This is less generic than the suggestion above, but would not >> require changing code and might be an improvement over what's >> there now. >> >> >> 2) Perhaps if the spec language were clarified and used the >> "OAuth 2.0 protected resource" language, the Initial Access Token >> term could be removed from the document entirely. I don't think >> the previous drafts got it right, but I think we can do better >> than those explanations while still avoiding giving a fancy name >> to something that is *just* an OAuth 2.0 Access Token. >> >> --Amanda >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
- Re: [OAUTH-WG] LC Review of draft-ietf-oauth-dyn-… Justin Richer
- Re: [OAUTH-WG] LC Review of draft-ietf-oauth-dyn-… Richer, Justin P.
- [OAUTH-WG] LC Review of draft-ietf-oauth-dyn-reg-… Anganes, Amanda L
- Re: [OAUTH-WG] LC Review of draft-ietf-oauth-dyn-… Anganes, Amanda L
- Re: [OAUTH-WG] LC Review of draft-ietf-oauth-dyn-… Phil Hunt