[OAUTH-WG] Review Comments for draft-ietf-oauth-proof-of-possession-02

Nat Sakimura <sakimura@gmail.com> Wed, 25 March 2015 13:37 UTC

Return-Path: <sakimura@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 76AB61A1BC3 for <oauth@ietfa.amsl.com>; Wed, 25 Mar 2015 06:37:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flsAv1Bn2dTs for <oauth@ietfa.amsl.com>; Wed, 25 Mar 2015 06:37:53 -0700 (PDT)
Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (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 887501A0119 for <oauth@ietf.org>; Wed, 25 Mar 2015 06:37:53 -0700 (PDT)
Received: by obcjt1 with SMTP id jt1so19311564obc.2 for <oauth@ietf.org>; Wed, 25 Mar 2015 06:37:53 -0700 (PDT)
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=zdTH4FPcZq6SiacwEoBDXmGoq8jPs+Qt/zKuPhQjgOU=; b=ATp+jsKsU0bkFIZtAKhSQt17NCcacgjsANZyUrip75Ym7CM6YOPtlRH0yBXqC2xFbJ IiG5Y34brVC8WxaWl5axMz2wa+Mq09VKLDXKmimpks1/YiPNFNTF4qkzhD22DSskVVBw 9pKkPYJepgF/aMAAaIGa9UihlAnbDJOPBcRTBxZUrPtMPtrV+vwCUfSc32Oo0wmBK71x J663VUYYdZviJpI3s5z/dkMkNcMJaqEuN17tWv3FHttGaLeljjsYlLNnoQjhFVKKOj/f d2UP/27NV7beCOFAcnc5Ieg5lFw60bwUoj+9g3PMad8dZqVP6xS+duhvC496RGQc1Ot/ 79Og==
MIME-Version: 1.0
X-Received: by 10.182.210.197 with SMTP id mw5mr7707399obc.26.1427290673020; Wed, 25 Mar 2015 06:37:53 -0700 (PDT)
Received: by 10.60.141.230 with HTTP; Wed, 25 Mar 2015 06:37:52 -0700 (PDT)
Date: Wed, 25 Mar 2015 22:37:52 +0900
Message-ID: <CABzCy2CRdmH35z5b=oL4sE9qJd=t_xCcg=Fds_orrgtYL2KeNw@mail.gmail.com>
From: Nat Sakimura <sakimura@gmail.com>
To: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c29be88e880805121d0128
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/POq_ZSZkWtg8y6OlndDQYkJrRI4>
Subject: [OAUTH-WG] Review Comments for draft-ietf-oauth-proof-of-possession-02
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, 25 Mar 2015 13:37:56 -0000

Dear OAuthers:

Here is my belated review comments on
draft-ietf-oauth-proof-of-possession-02

Below, [POPA] stands for
https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01

Abstract
============
It is probably better to spell out that this document is describing the JWT
format that can be used for sender constraint (5.2 of [POPA]) and key
confirmation (5.3 of [POPA]). This will make it easier for the reader to
understand what this document aims at.

Accordingly, we should consider the title change to something like:
JWT Sender Confirmation Token Syntax
  OR
borrowing from the financial concept which I believe is the origin of the
concept of "bearer token",
JWT Registered Token Syntax
-- here, "Registered" mean that either the sender constraint or key
confirmation is registered within or in conjunction with the token.

1. Introduction
==============
Consider referencing draft-ietf-oauth-pop-architecture.
It will be clearer for the reader then, and the text will be shorter.

2. Terminology - Presenter
========================
Sentence 1
-------------------
Not sure if the first sentence is accurately reflecting the intent.
It excludes rogue party presenting the token (and fails) from presenter.
If so, it is fine but using more qualified term like "authorized presenter"
may make it easier
for the reader to parse.

Otherwise revise the definition.

Sentence 2
-------------------
"issuer or a party different from the issuer" is not constraining anything
and meaningless.
There are more easier to parse and accurate text coming in the main text,
too.
Drop.

3. Proof-Of-Posession Representation
==============================
Title
---------
Perhaps "Sender Representation in JWT" is more reflective of the content.

Para 2
-------------
The paragraph describes two ways of sender confirmation:
(1) Sender Constraint
(2) Key Confirmation
It should refer to 5.2 and 5.3 of [POPA] for it, as well as align the
terminology.

Then, it goes on to describe (1) very briefly, in which it is just spelling
out "iss" and "sub".

I understand the use of sub in this section comes down from SAML but I feel
that some separation between sub and presenter would be nice.

For example, when I am presenting the token using an app that I installed
on my iPhone, the presenter is that app and not me, while the sub still may
be me. The app is the authorized presenter/party (azp) of the token. The
JWT may well be about the sub but presented by some software component that
should be independently identified.

So my proposal is to create a new subsection on (1) for the completeness,
which is going to be a new 3.1, and to use a claim like "azp" instead of
"sub" to identify the presenter. Less overload would cause less confusion
later, IMHO.

3.1
======
Title
--------
Perhaps "Confirmation Key Representation for an Asymmetric Key" is more
reflective of the content.

3.2
========
Title
-----------
Perhaps "Confirmation Key Representation for a Symmetric Key" is more
reflective of the content.

Last Para
-----------------
I feel a bit like needing to sniff into the content of jwk to find out what
type may not be optimal, though I do not have a concrete proposal a this
time.

3.3
======
Title
---------
Perhaps "Confirmation Key Representation by Key ID" is more reflective of
the content.

Para 1
-----------
There has been some discussion of using thumbprint instead of a blob "kid".
This is a valid option. If we are to overload the "kid" member for this
purpose, we need to find a way to signal that it is a thumbprint.
It may very well be better to define a separate member name then for the
thumbprint. The title then changes to "-- by Key ID" to "-- by reference".

Also, it is conceivable to use the combination of "kid" and "jku". This
aspect is not spelled out here but appears that some magic happens for the
key distribution.

3.4
========
Since "cnf" appears before 3.4, it may be better to bring 3.4 at the front.

5.2.2
=========
Add "azp" and "jkt".

o  Confirmation Method Value: "azp"
o  Confirmation Method Description: Client ID of the Authorized Presenter
o  Change Controller: IESG
o  Specification Document(s): Section [TBD] of [[ this document ]]


o  Confirmation Method Value: "jkt"
o  Confirmation Method Description: JWK Thumbprint of the Confirmation Key
o  Change Controller: IESG
o  Specification Document(s): Section [TBD] of [[ this document ]]


o  Confirmation Method Value: "jku"
o  Confirmation Method Description: JWK URI of the Confirmation Key
o  Change Controller: IESG
o  Specification Document(s): Section [TBD] of [[ this document ]]

Privacy Consideration
========================
It is missing privacy consideration. It is not required per se, but since
Key Confirmation method with ephemeral key can be less privacy intrusive
compared to other sender confirmation method so adding some text around it
may be a good idea.

Best,
-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en