[OAUTH-WG] AD review of Draft-ietf-dyn-reg
Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Wed, 11 February 2015 23:07 UTC
Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25A21A873E for <oauth@ietfa.amsl.com>; Wed, 11 Feb 2015 15:07:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROy0D-ibqENk for <oauth@ietfa.amsl.com>; Wed, 11 Feb 2015 15:06:54 -0800 (PST)
Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CBC61A8734 for <oauth@ietf.org>; Wed, 11 Feb 2015 15:06:54 -0800 (PST)
Received: by labgm9 with SMTP id gm9so6647291lab.2 for <oauth@ietf.org>; Wed, 11 Feb 2015 15:06:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=BPQwdvuqoQrZ/0qzYF2lYZ2xnqr5aa5mKWDqFSVNl8A=; b=ZDH4RNHB6RoGLRStSk081Bg1eG+Fyf2XBdb7HH+yqaevhPnT5dbBofZB3T49gzrVgv Yp56c1j8O1fcS+xgExPQIN6T0ZDOFFgTfIujjcUCltgx1TYMtQxtwEEyfbowlD4q/uo2 hmC6uBK0guHK9OLmxLCSjY6UeW0fdY3nCLSht39L9Xz7kMC3Lp1DYkR4d3hFvYFBJIGX f7w4cl27rccUKtmbpRfgsz0cpdp9cJSiM4p2XvkmPxKWofZmZTCrzmntzifxSGid8XOD RA/f0ij2W6QkCCYHeal6Y0jpLWent2IL4cVIX2khhtMKl3h3DQnid1VwilEq7qjeXF6P gUdw==
MIME-Version: 1.0
X-Received: by 10.112.9.38 with SMTP id w6mr680819lba.113.1423696012054; Wed, 11 Feb 2015 15:06:52 -0800 (PST)
Received: by 10.112.167.101 with HTTP; Wed, 11 Feb 2015 15:06:51 -0800 (PST)
Date: Wed, 11 Feb 2015 18:06:51 -0500
Message-ID: <CAHbuEH587HcqaqTMrmLPXQimRAaS2j1Uv+BC-0UHeyBwC8+3Uw@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="001a1134deb81115bd050ed80f27"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/705PHAu0P6ZmKlBkW4KOol5CzE4>
Subject: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 11 Feb 2015 23:07:08 -0000
X-List-Received-Date: Wed, 11 Feb 2015 23:07:08 -0000
Thank you for your work on this draft and sorry for the delay in my review. Before we progress to IETF last call, I'd like to see what we can resolve from the list below. I am looking at the IPR issues to see if we can resolve the outstanding questions as well. The Shepherd report says the following: The document shepherd has raised concerns regarding the fuzzy description of the actors (deployment organization, software API publisher, client developer) and their impact on the protocol execution. The working group did not seem to worry about these aspects though. I can see the point after reading the draft. The interactions are written much more clearly in the security considerations section than where the flows are described. Can something be done to address these concerns? Section 1.2 Deployment Organization definition: I highly recommend replacing the phrase "simple cloud deployment" with a description that accurately reflects what is intended. If that's within a single service provider's network, a single data center, or a single hosted data center, I think it would be more clear. Section 1.2 nit: Add the word "be" into the following term definition after "may": Software API Publisher The organization that defines a particular web accessible API that may deployed in one or more deployment environments. Section 2: Why isn't a more secure option offered and set as the default for authentication types? I know I've asked this before and the answer was just that you can add something to the registry, but setting HTTP Basic as the default seems like a really bad choice. HOBA is on it's way to becoming an RFC from the HTTPAuth working group. HTTPAuth also has an updated version of Basic that is in IETF last call, but I know you are pointing to the OAuth 2.0 document, so it would be that document that gets updated and not this draft. The new version of HTTP Basic fixes some internationalization problems and spells out the security issues much more clearly, so it probably doesn't matter too much to update the reference, but maybe makes it more clear that basic is not a secure form of authentication. Can you provide some justification as to why this is okay to set basic as the default and add that to the draft? Section 2.3.1 of OAuth 2.0 just says this MUST be implemented, but that any HTTP schemes can be used. Why not register another method and use that instead as the default? You could use digest and there is library support. It's not a great answer, but slightly better than passwords with basic. You could register HOBA and use that instead, the only downside is limited library support at the moment. Section 2: Contacts: I noticed privacy is not dealt with until you get to the security considerations section. I'd prefer to see it with the definition, stating the address should be a general help address at the domain rather than directly to an identifiable individual. It may be good to set a default for what this should be for consistency or give an example (think back to abuse@domain.com)? Software_id and software_version: Are there any guidelines as to how these should be represented? There are several specifications on software_id (and platform). Does consistency here matter or is this just meant to be human readable? Section 2.2 specifies some metadata values that are to be human readable, should the above be in the list? I would expect this list to be comprehensive for clarity, rather than just examples since there aren't too many defined here. Section 3.2.1 & Privacy section For client_name and client_id and associated information, how is user privacy affected and what can be done to mitigate concerns? The definition should state that this is a public value and that it is specific to the software, not a person. You have to get to the security consideration section before that is clear. References are fine too, but some more information is needed in the privacy section. I'm left with a bunch of questions: Can the client_name and client_id be tied to a person? Can the person be tracked by this? Can other information be gathered about a system (and it's user) during this process? The information is used to dynamically register clients, what is logged? What data is aggregated? What can you tell about a client (time, location, travel, other personal details that may be considered sensitive)? I don't think this was covered in the OAuth 2.0 RFC. How is this addressed at the authorization server and other points? The Security considerations talks about client_id as being short lived, so they expire, but are these event logged or is that prohibited? 5. Security considerations The first paragraph is a repeat of text. Can this just be in one place and use a pointer to the full text? I like the requirement, but reading it once is enough. -- Best regards, Kathleen
- [OAUTH-WG] AD review of Draft-ietf-dyn-reg Kathleen Moriarty
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Justin Richer
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Phil Hunt
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Mike Jones
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Justin Richer
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Phil Hunt
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Kathleen Moriarty
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Kathleen Moriarty
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg John Bradley
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Kathleen Moriarty
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Justin Richer
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Hannes Tschofenig
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Hannes Tschofenig
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Sam Hartman
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Kathleen Moriarty
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Kathleen Moriarty
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Mike Jones
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Kathleen Moriarty
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Bill Burke
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Mike Jones
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Kathleen Moriarty
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg John Bradley
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg John Bradley
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Kathleen Moriarty
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Justin Richer
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Kathleen Moriarty