[OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Tue, 24 November 2015 17:44 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 0A8AA1B300B for <oauth@ietfa.amsl.com>; Tue, 24 Nov 2015 09:44:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id OLRTehm8BNYL for <oauth@ietfa.amsl.com>; Tue, 24 Nov 2015 09:44:09 -0800 (PST)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 6563D1B2FFD for <oauth@ietf.org>; Tue, 24 Nov 2015 09:44:09 -0800 (PST)
Received: by wmww144 with SMTP id w144so149046379wmw.1 for <oauth@ietf.org>; Tue, 24 Nov 2015 09:44:08 -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=mm4o4q9sBIJKsN8Xq4nuOuP9iSASoNjwIR1CokWjYyk=; b=AGYTvHmyqD8NSa/ieqbvKJ3G3585wKEaXgWisbVXx6rU8b2P4ph5QlSagwihXVmxNh Rn5IyUIUfxgUsFlA3cWdmymvyZAL8NGfZqZTekpRd+69UIxQW5Fy4trE6e/wzhmKTbuZ GNSq0gSZhMRxYBqh54CTvrcEw9xBroyC/BWZ56h4p9MI3jMXOsuGOFHPSx+9k8OB6H3O iK3MGFudKlXxnwQfro3eaCR35Wt0EWWb9KQLVY0lAK3whLut/uYZbkKrxGdD3wsP8nwP yjSXJyLcd3NXLJ/zaCuCST1+h1cf32wT1QMJ9DM6oHOhDb7ms7bb8UmAeixjnd4Z/NoY 7ACQ==
MIME-Version: 1.0
X-Received: by with SMTP id z206mr25028443wmc.71.1448387047942; Tue, 24 Nov 2015 09:44:07 -0800 (PST)
Received: by with HTTP; Tue, 24 Nov 2015 09:44:07 -0800 (PST)
Date: Tue, 24 Nov 2015 12:44:07 -0500
Message-ID: <CAHbuEH4J5SYVuWe5+OHfCQARuZhOJ6hG=5RqUkh5Ebad_RneAg@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/vaLCbGqLeGka7hLOa9t1Yxa7-bo>
Subject: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession
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: <https://mailarchive.ietf.org/arch/browse/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, 24 Nov 2015 17:44:11 -0000


Thank you all for your work on this draft!  I just have a few questions:

1. Security considerations section says:

"All of the normal security issues, especially in relationship to
   comparing URIs and dealing with unrecognized values, that are
   discussed in JWT [JWT] also apply here."

I find that to be odd phrasing that would likely be picked up in
subsequent reviews.  Please remove the word "normal" so that all of
the security issues discusses in JWT are included.  Are there other
'normal considerations in addition to those in JWT that need to be
listed?  The phrasing reads as if that may the case and would be
better to include them all or pointers or change the phrasing.

2. Also in the security considerations section,

   "A recipient may not understand the newly introduced "cnf" claim and
   may consequently treat it as a bearer token."

What is the proper handling requirement when an unknown claim is
present?  Section 3.1 says:
  "When a recipient receives a "cnf" claim with a
   member that it does not understand, it MUST ignore that member."

Is this why it is treated as a bearer token rather than being
rejected?  Is this really the action you want to see with cnf?  Why
isn't there an error and a resend as a bearer token so that parties
understand (or have an opportunity to understand) that there were

Then the following text in the security section says:
  "While this is a
   legitimate concern, it is outside the scope of this specification,
   since demonstration the possession of the key associated with the
   "cnf" claim is not covered by this specification. For more details,

How is this outside of the scope of this draft?  cnf is defined in
this draft, so handling should be covered in this draft.  A pointer to
the POP architecture draft is not helpful as it is not defined there,
it's covered int his draft.  Should this text just be removed and
replaced with more explicit handling information int he body of this



Best regards,