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

[Mike Jones <[e-mail]>]

I typically do respond to review comments line-by-line but ran out of time to do this before Prague.  (I was doing things like working with Brian on the Token Exchange deck, preparing my remarks to the COSE WG, etc.)  I’ll plan to do this sometime early next week, which is the soonest I’ll be able to get to it, given other things currently on my plate.

FYI, I did read through all of your and other’s comments and applied most of them – for instance, off the top of my head, clarifying how “azp” could be used in identifying the presenter, eliminating the need to sniff the “jwk” value, and updating the title to be more evocative of what the specification actually achieves.

                                                            Cheers,
                                                            -- Mike

From: OAuth [mailto:[e-mail]] On Behalf Of Nat Sakimura
Sent: Thursday, July 30, 2015 6:36 PM
To: oauth
Subject: Re: [OAUTH-WG] Review Comments for draft-ietf-oauth-proof-of-possession-02

I cannot find any disposition of comment (DoC) to this review that the WG Chairs asked.
Nor I see much of them reflected in -03.

The process I would imagine to be the editors to

1) Provide the DoC [accept, discuss, reject (with reasons)],
2) Open up series of discussions on discuss items and drive towards the (rough) consensus.

Since the diff between -02 and -03 is small, much of the above comments still applies.

Looking forward to see the DoC.

Nat

2015-03-25 22:37 GMT+09:00 Nat Sakimura <[e-mail]<mailto:[e-mail]>>:
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<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-pop-architecture-01&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8e3a1c80800044afea6408d299487914%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=aAlUfVrPuS6gZpFdW89pHCw2DWrRcftagluPdgF3XzQ%3d>

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/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnat.sakimura.org%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8e3a1c80800044afea6408d299487914%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AkE994JMtcV9SGK3yaZ9beCp4r4RIMn9Fs%2bZU9ESdeM%3d>
@_nat_en



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnat.sakimura.org%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8e3a1c80800044afea6408d299487914%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AkE994JMtcV9SGK3yaZ9beCp4r4RIMn9Fs%2bZU9ESdeM%3d>
@_nat_en