Thanks. I am working on your response now. 2015-08-11 14:24 GMT+09:00 Mike Jones <michael.jo...@microsoft.com>:
> 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:oauth-boun...@ietf.org <oauth-boun...@ietf.org>] *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 <sakim...@gmail.com>: > > 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
