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

[Nat Sakimura <[e-mail]>]

Thanks. I am working on your response now.

2015-08-11 14:24 GMT+09:00 Mike Jones <[e-mail]>:

> I believe that I’ve now responded line-by-line to all the WGLC comments
> received.  If I missed any from any of you, please let me know.
>
>
>
> After discussion of my responses this week, unless disagreements arise,
> I’ll plan to publish -04 next week to incorporate the remaining resolutions
> that have been discussed and planned for the next draft, such as allowing
> symmetric keys in encrypted JWTs to be represented as simple JWKs in the
> “jwk” claim.
>
>
>
>                                                             Best wishes,
>
>                                                             -- Mike
>
>
>
> *From:* Mike Jones
> *Sent:* Thursday, July 30, 2015 7:49 PM
> *To:* 'Nat Sakimura'; oauth
> *Subject:* RE: [OAUTH-WG] Review Comments for
> draft-ietf-oauth-proof-of-possession-02
>
>
>
> 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] <[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]>:
>
> 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
>



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