FYI, I posted about the availability of the new draft at http://self-issued.info/?p=1468 and as @selfissued<https://twitter.com/selfissued>.
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Monday, October 19, 2015 4:02 PM To: Kepeng Li; oauth@ietf.org Subject: Re: [OAUTH-WG] Review comments to PoP document Hi Kepeng, Draft -05 addresses all your review comments as agreed below, other than adding the diagrams that you requested. I’ll plan on working on those between now and Yokohama and submitting an updated draft with the diagrams when the submission period opens. Thanks again for your useful review of this draft. I added you to the acknowledgements. Best wishes, -- Mike From: Kepeng Li [mailto:kepeng....@alibaba-inc.com] Sent: Thursday, October 08, 2015 6:04 PM To: Mike Jones; oauth@ietf.org<mailto:oauth@ietf.org> Subject: Re: Review comments to PoP document Hi Mike, Thanks for your responses. About the first paragraph in the introduction, I would prefer to make it different from the same one in the abstract. I am fine with others. Kind Regards Kepeng 发件人: Mike Jones <michael.jo...@microsoft.com<mailto:michael.jo...@microsoft.com>> 日期: Friday, 9 October, 2015 1:58 am 至: Li Kepeng <kepeng....@alibaba-inc.com<mailto:kepeng....@alibaba-inc.com>>, "oauth@ietf.org<mailto:oauth@ietf.org>" <oauth@ietf.org<mailto:oauth@ietf.org>> 主题: RE: Review comments to PoP document Thanks for the useful review, Kepeng. Responses inline… From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Kepeng Li Sent: Wednesday, October 07, 2015 7:30 AM To: oauth@ietf.org<mailto:oauth@ietf.org> Subject: [OAUTH-WG] Review comments to PoP document Hello all, Please find my review comments to PoP document: http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-proof-of-possession-04&data=01%7c01%7cMichael.Jones%40microsoft.com%7c39fc367bfc044fe9243c08d2cf23d95b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=XNX89l21GzCoKDzkQufdN1vF9VsGqOpNpWp9M6yyqAQ%3d> 1、 Title: Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) [Kepeng] Should we add OAuth 2.0 in the title? Also, in the whole document, we use JWT, but in the title, we use “JWTs”. Is there a reason for this? I wouldn’t suggest adding “OAuth 2.0” to the title, in part, because JWTs are used in contexts outside of OAuth. As for why JWTs is plural here, the title is saying that PoP keys can be communicated in JSON Web Tokens. If it were singular, it would sound like you could only use PoP keys in a single JWT, which isn’t right. 2、 Abstract： 1) This specification defines how to express a declaration in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular key and that the recipient can cryptographically confirm proof-of-possession of the key by the presenter. [Kepeng] Add reference to JWT. I’ve been told when editing other drafts to remove references that I’d placed in abstracts, since IETF abstracts don’t include references. 2) This property is also sometimes described as the presenter being a holder-of-key. [Kepeng] I am not sure what is “this property”. Do you mean “the key”? If yes, just use the key. And change the sentence to something like: This key is also sometimes described as a holder-of-key by the presenter. I can change “This property” to “Being able to prove possession of a key”. 3. Introduction 1) The first paragraph is the same as the abstract. I suggest to reword it a little bit or remove it, to avoid the redundancy. The rest of the introduction builds on the ideas introduced in the first two sentences (the content of the abstract). If they were to be removed, it would make the introduction confusing, as many people won’t start by reading the abstract, but will read the introduction independently. (The introduction does add references, which cannot be present in the abstract.) I’ll work with the other editors to see if they want to reword the first two sentences of the introduction and/or abstract to make them different from one another. 2) See [I-D.ietf-oauth-pop-architecture] for a further discussion of key confirmation. [Kepeng] I suggest to mention a little bit more about the relationship between PoP architecture document and this document. In my understanding, in PoP architecture document, it mentions several mechanisms: confidentiality protection, key confirmation and sender constraint. This document introduces the key semantics for the key confirmation mechanism. OK – we can say that [I-D.ietf-oauth-pop-architecture] describes key confirmation, among other conformation mechanisms, and that this specification defines how to communicate key confirmation key information in JWTs. 3) About the two use cases, it will be useful to use two diagrams or flows to indicate how it works. Maybe put these two flows in a separate section. Also it will be useful to mention which step is in scope, and which is out of scope, e.g. how to convey symmetric key from the issuer to the presenter. Both are in scope, which is why they’re both described in the introduction. I’ll work with the other editors on trying to create appropriate diagrams. 4. Section 3: 1) It will be useful to put a reference to "sub" (subject) claim, and "iss" (issuer) claim. OK 2) Note that if an application needs to represent multiple proof-of- possession keys in the same JWT, one way for it to achieve this is to use other claim names, in addition to "cnf", to hold the additional proof-of-possession key information. [Kepeng] It is not clear, what are the other claim names? Fair point. We can say that those claim names would be defined by applications and could be registered in the JWT Claims Registry. Kind Regards Kepeng Thanks again! -- Mike
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
