Re: [OAUTH-WG] Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-27: (with COMMENT)
> -Original Message- > From: Ted Lemon [mailto:ted.le...@nominum.com] > Sent: Monday, October 06, 2014 12:49 PM > To: Mike Jones > Cc: The IESG; oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web- > to...@tools.ietf.org; oauth@ietf.org > Subject: Re: Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-27: > (with COMMENT) > > On Oct 6, 2014, at 3:54 AM, Mike Jones > wrote: > > Sometimes authenticated encryption alone is good enough without requiring a > signature. Different applications will have different requirements. So > while this > section discussion the applicable considerations, the working group felt that > it > was going too far to make this prescriptive. > > But if you don't need to sign the message, why sign it? The working group isn't advocating signing the token if it's not necessary. The clause we're discussing is just intended to provide guidance to application architects in the case that both signing and encryption are necessary. I propose that we add language about "If both signing and encryption are necessary" in order to make the context of this advice clear. Would that resolution be acceptable to you, Ted? -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)
Thanks for tracking all of this Stephen. Responses inline below... > -Original Message- > From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] > Sent: Monday, October 06, 2014 2:43 PM > To: Mike Jones; The IESG > Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web- > to...@tools.ietf.org; oauth@ietf.org > Subject: Re: Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: > (with DISCUSS and COMMENT) > > > Hi Mike, > > On 06/10/14 08:54, Mike Jones wrote: > > Thanks for your review, Stephen. I've added the working group to the > > thread so they're aware of your comments. > > > >> -Original Message- From: Stephen Farrell > >> [mailto:stephen.farr...@cs.tcd.ie] Sent: Thursday, October 02, 2014 > >> 5:03 AM To: The IESG Cc: oauth-cha...@tools.ietf.org; > >> draft-ietf-oauth-json-web- to...@tools.ietf.org Subject: Stephen > >> Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with > >> DISCUSS and COMMENT) > >> > >> Stephen Farrell has entered the following ballot position for > >> draft-ietf-oauth-json-web-token-27: Discuss > >> > >> When responding, please keep the subject line intact and reply to all > >> email addresses included in the To and CC lines. (Feel free to cut > >> this introductory paragraph, however.) > >> > >> > >> Please refer to > >> http://www.ietf.org/iesg/statement/discuss-criteria.html for more > >> information about IESG DISCUSS and COMMENT positions. > >> > >> > >> The document, along with other ballot positions, can be found > >> here: > >> http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ > >> > >> > >> > >> - > >> - > >> > >> > DISCUSS: > >> - > >> - > >> > >> > >> > >> > (1) 4.1.1 and elsewhere you say case-sensitive: the same thing I raised wrt > DNS > >> names for another JOSE spec - do you need to say those SHOULD be > >> [upper|lower]cased when used in these? > > > > I believe that somewhere we should say that if case-insensitive > > values, such as DNS names, are used when constructing "kid" values, > > that the application doing so needs to define a convention on the > > canonical case to use for the case-insensitive portions, such as > > lowercasing them. > > As that discussion's happening on the key draft, I'll clear it here and trust > you to > fix if a change is the end result. Thanks > >> (2) Section 8: Why is "none" MTI? That seems both broken and going in > >> the oppostite direction from other WGs and so should be explicitly > >> jusified I think. (If a good enough justification exists that is.) > > > > It is MTI because there are several existing applications of JWTs in > > which both unsigned and signed representations of the JWTs are > > requirements. These include draft-ietf-oauth-token-exchange, > > draft-hunt-oauth-v2-user-a4c, and OpenID Connect. This is a pretty > > common pattern where you sign something if the recipient cares who > > made the statements and where you don't have to sign it either if the > > recipient doesn't care who made the statements > > I don't see how (non-)signers can divine non-verifier's wishes that way. > (Absent > negotiation or a directory.) Sometimes it does occur via negotiation. For instance, in some protocols, at registration time, relying parties explicitly tell identity providers what algorithms are acceptable to them, which may include "none". No divination - explicit communication. > > or if it can tell from > > another secured aspect of the application protocol (typically through > > the use of TLS) who made the statements. In the TLS case, the server > > authentication step makes a signature step unnecessary, so an > > Unsecured JWT is fine there. > > That's arguable IMO. I agree that it's application and context-dependent whether it's OK or not. The point is that there exist some circumstances in which it is OK, and this feature is being used in some of those cases. > I think I'll look back over the wg thread and either hold my nose or This issue was tracked as http://trac.tools.ietf.org/wg/jose/trac/ticket/36. Karen O'Donoghue recorded this conclusion in the tracker "Note: There was extensive discussion on the mailing list, and the rough consensus of the working group was to leave "none" in the document." Discussion threads on this topic include: [jose] #36: Algorithm "none" should be removed http://www.ietf.org/mail-archive/web/jose/current/msg02911.html - Began Jul 31, 2013 (91 messages) [jose] Text about applications and "alg":"none" http://www.ietf.org/mail-archive/web/jose/current/msg03321.html - Began Sep 3, 2013 (5 messages) This issue was a topic of a special working group call on Aug 19, 2013. The text discussed in the last thread and published at https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-33#section-8.5 (Unsecured JWS Security Considerations) was the
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)
While my personal preference is to not release PII as part of authentication, We do have people demanding attributes in SAML and Connect at LoA 2+ for identity resolution at the relying party. https://www.idmanagement.gov/sites/default/files/documents/FICAM_TFS_ATOS.pdf (see Appendix A) JWT is used in much more than just OAuth these days. John B. On Oct 6, 2014, at 6:42 PM, Stephen Farrell wrote: >> >> but sometimes the very >> point of a JWT is to securely deliver PII from a verifiable party to >> an intended party with appropriate rights to receive it. > > Hmm. Its a moot point (so let's not argue it) but I wonder how > often PII is really needed for authorization with oauth. My guess > would be that its needed far less often than its found to be > profitable perhaps, or that carelessness plays a big role in > using PII for such purposes. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)
Hi Mike, On 06/10/14 08:54, Mike Jones wrote: > Thanks for your review, Stephen. I've added the working group to the > thread so they're aware of your comments. > >> -Original Message- From: Stephen Farrell >> [mailto:stephen.farr...@cs.tcd.ie] Sent: Thursday, October 02, 2014 >> 5:03 AM To: The IESG Cc: oauth-cha...@tools.ietf.org; >> draft-ietf-oauth-json-web- to...@tools.ietf.org Subject: Stephen >> Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with >> DISCUSS and COMMENT) >> >> Stephen Farrell has entered the following ballot position for >> draft-ietf-oauth-json-web-token-27: Discuss >> >> When responding, please keep the subject line intact and reply to >> all email addresses included in the To and CC lines. (Feel free to >> cut this introductory paragraph, however.) >> >> >> Please refer to >> http://www.ietf.org/iesg/statement/discuss-criteria.html for more >> information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found >> here: >> http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ >> >> >> >> -- >> >> DISCUSS: >> -- >> >> >> >> (1) 4.1.1 and elsewhere you say case-sensitive: the same thing I raised wrt DNS >> names for another JOSE spec - do you need to say those SHOULD be >> [upper|lower]cased when used in these? > > I believe that somewhere we should say that if case-insensitive > values, such as DNS names, are used when constructing "kid" values, > that the application doing so needs to define a convention on the > canonical case to use for the case-insensitive portions, such as > lowercasing them. As that discussion's happening on the key draft, I'll clear it here and trust you to fix if a change is the end result. > >> (2) Section 8: Why is "none" MTI? That seems both broken and going >> in the oppostite direction from other WGs and so should be >> explicitly jusified I think. (If a good enough justification exists >> that is.) > > It is MTI because there are several existing applications of JWTs in > which both unsigned and signed representations of the JWTs are > requirements. These include draft-ietf-oauth-token-exchange, > draft-hunt-oauth-v2-user-a4c, and OpenID Connect. This is a pretty > common pattern where you sign something if the recipient cares who > made the statements and where you don't have to sign it either if the > recipient doesn't care who made the statements I don't see how (non-)signers can divine non-verifier's wishes that way. (Absent negotiation or a directory.) > or if it can tell from > another secured aspect of the application protocol (typically through > the use of TLS) who made the statements. In the TLS case, the server > authentication step makes a signature step unnecessary, so an > Unsecured JWT is fine there. That's arguable IMO. I think I'll look back over the wg thread and either hold my nose or > >> (3) Section 12: another way to handle privacy is to not include >> sensitive data - I think you ought mention that as a bit of thought >> along those lines can be much simpler than putting in place the key >> management to handle thoughtlessly included PII. > > We can include a discussion of that point, Great. "Just say no" is workable here:-) I'll clear when we get such text. > but sometimes the very > point of a JWT is to securely deliver PII from a verifiable party to > an intended party with appropriate rights to receive it. Hmm. Its a moot point (so let's not argue it) but I wonder how often PII is really needed for authorization with oauth. My guess would be that its needed far less often than its found to be profitable perhaps, or that carelessness plays a big role in using PII for such purposes. S. > >> -- >> >> COMMENT: >> -- >> >> >> >> - abstract: 2nd sentence isn't needed here, in intro would be fine. > > I don't know - I think it's a big deal that the claims can be > digitally signed or MACed and/or encrypted. That's the reason we > have JWTs, rather than just JSON. > >> - 4.1.7: maybe worth adding that jti+iss being unique enough is not >> sufficient and jti alone has to meet that need. In X.509 the >> issuer/serial has the equivalent property so someone might assume >> sequential jti values starting at 0 are ok. > > Makes sense to add a warning of some kind along these lines. I think > I know the reasons you say that, but can you expand on that thought a > bit before I take a stab on writing this up? For instance, while > normally true, I don't think your observation is true if a relying > party will only accept tokens from a single issuer. > >> - section 6: yuk >> >> - again I think the secdir comments are being handled by Kat
Re: [OAUTH-WG] Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-27: (with COMMENT)
On Oct 6, 2014, at 3:54 AM, Mike Jones wrote: > Sometimes authenticated encryption alone is good enough without requiring a > signature. Different applications will have different requirements. So > while this section discussion the applicable considerations, the working > group felt that it was going too far to make this prescriptive. But if you don't need to sign the message, why sign it? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Secdir Review of draft-ietf-oauth-jwt-bearer-10
Thanks for your review, Radia. I've added the working group to the thread so that they're aware of your comments. > From: Radia Perlman [mailto:radiaperl...@gmail.com] > Sent: Monday, September 29, 2014 4:46 PM > To: sec...@ietf.org; The IESG; draft-ietf-oauth-jwt-bearer@tools.ietf.org > Subject: Secdir Review of draft-ietf-oauth-jwt-bearer-10 > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document is one of a set of documents specifying how to use JSON > formatted OAuth bearer tokens in the context of HTTP requests. > > It specifies two contexts in which these JSON tokens can be used: as > Authorization Grants or for Client Authentication. It specifies the > to-be-IANA-registered parameters used to specify that the type of token > presented is a JSON token (within the HTTP header). It also specifies the > checks to be done to validate that the JSON token is valid (though I would > expect this information would also be specified in the JSON token > specification itself). You're right that some of the validation rules are in draft-ietf-oauth-json-web-token, which defines the basic JWT token format, however this specification adds some additional validation rules because it requires that some fields be present that are optional in the JWT spec, and it specifies that they be used in a particular way. > There are security considerations and privacy considerations sections, but > they are very light. That is because it refers to > draft-ietf-oauth-assertions-17, which has a more complete security > considerations section. I guess it's appropriate to have more detailed > security considerations there, since all this specification adds is some > labels. Yes, this was the intent. Most of the security considerations are independent of the token type. > Would it make sense to merge this document with the other specs, rather than > having this be so redundant with the others? No, because while there's semantic commonality, the syntax of the SAML profile and the JWT profile are different. Merging them would make it much harder to read because it would be full of conditionals depending upon which token format was being described. > Some details: > > On page 3 para 2, it says “The format and processing rules for the JWT > defined in this specification are intentionally similar, though not > identical, to those in the closely related SAML 2.0 Profile for OAuth.” It > would be good if they specified what the differences are, and why they > couldn't be identical. That's a fair point. I'll look into this with the other editors and the working group. The following comments in the JWT profile spec record SAML features used for which no equivalent JWT feature exists. This might be good material to put into an appendix. > Some background guidance on when you would want to use a token for client > authentication vs. when you would want to use one for an authorization grant > would be useful. In practice, the distinction between the two is subtle. It > is common for a token to contain the caller’s identity as well as group > memberships and perhaps roles. I suspect the reality is that the client has > to figure out which protocol slot the server wants to get the token in and > provide it there, where service designers make the decision more or less > arbitrarily. This guidance really belongs in the generic assertions specification draft-ietf-oauth-assertions. I'll plan on reviewing that spec with the other editors and the working group to see whether the guidance provided there needs to be improved. > Page 6 item 4: “The authorization server MAY reject JWTs with an “expiration” > claim that is unreasonably far in the future.” This is saying that the > validator of the token might choose to reject tokens that are long lived. > It’s not clear what the user of this spec can do with this information. It > calls for some out-of-band communication between the token issuer and the > token validator on what is an acceptable expiration period. Unless the > protocol has some way of reporting this back so that the caller can get a > shorter-lived token, it seems like a fragile design. What you write is true, but it' also a consequence of the fact that applications are free to impose additional requirements on the usage of this specification, provided their usage is still conforming. I believe that the text above should be modified to begin "Note that ..." to make it clear that this is informative, and not normative text. > Radia Thanks again, -- Mike ___
Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)
Thanks for your review, Richard. My responses are inline below... > -Original Message- > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Richard Barnes > Sent: Wednesday, October 01, 2014 7:57 PM > To: The IESG > Cc: oauth-cha...@tools.ietf.org; oauth@ietf.org; draft-ietf-oauth-json-web- > to...@tools.ietf.org > Subject: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web- > token-27: (with DISCUSS and COMMENT) > > Richard Barnes has entered the following ballot position for > draft-ietf-oauth-json-web-token-27: Discuss > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this introductory > paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ > > > > -- > DISCUSS: > -- > > Section 7. > In order to prevent confusion between secured and Unsecured JWTs, the > validation steps here need to call for the application to specify which is > required. Per my response on your JWS comments, this is already handed in a more general way in the JWS validation steps. Specifically, the last paragraph of Section 5.2 is: "Finally, note that it is an application decision which algorithms are acceptable in a given context. Even if a JWS can be successfully validated, unless the algorithm(s) used in the JWS are acceptable to the application, it SHOULD reject the JWS." I would therefore request that you likewise withdraw this DISCUSS on that basis. > -- > COMMENT: > -- > > Abstract. > Welsh is the only language I know of in which "w" is a vowel. According to > Wikipedia, then, "JWT" should pronounced "joot" :) You're not the only person with knowledge of Welsh to have made this comment. And this is a Jones responding to you... ;-) > Section 2. > It seems like "Unsecured JWT" should simply be defined as "A JWT carried in an > Unsigned JWS." It's been useful in other specifications that are applications of JWTs to have a name for this kind of JWT, since it occurs frequently. > Section 4.1. > I'm a little surprised not to see a "jwk" claim, which would basically enable > JWTs > to sub in for certificates for many use cases. Did the WG consider this > possibility? Not to my knowledge. However, I know of several applications in which JWKs and JWK Sets are carried as claims in JWTs of various kinds - just using claim names that are informed by the context of the particular application. For instance, draft-ietf-oauth-dyn-reg uses a "jwks_uri" claim to pass a JWK Set by reference and a "jwks" claim to pass a JWK Set by value. > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Thanks again, -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Gen-ART Last Call review of draft-ietf-oauth-saml2-bearer-21
Thanks for your review, Meral. I've added the working group to this thread so that they're aware of your comments. > From: Meral Shirazipour [mailto:meral.shirazip...@ericsson.com] > Sent: Monday, September 29, 2014 12:40 AM > To: draft-ietf-oauth-saml2-bearer@tools.ietf.org; gen-...@ietf.org > Subject: Gen-ART Last Call review of draft-ietf-oauth-saml2-bearer-21 > > I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, > please see the FAQ at > http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. > > Please resolve these comments along with any other Last Call comments you may > receive. > > Document: draft-ietf-oauth-saml2-bearer-21 > Reviewer: Meral Shirazipour > Review Date: 2014-09-29 > IETF LC End Date: 2014-09-29 > IESG Telechat date: NA > > > Summary: > This draft is ready to be published as Standards Track RFC . > > > Nits/editorial comments: > Nits: > -Abstract, please consider smelling out Security Assertion Markup Language Agreed > -[Page 4] Section 2.1 ",use an access ..", it would be clearer to name the > entity (AS?) who would have to "use and access token...". Agreed. I propose we say that the client does this. > -[Page 5] Section 2.2 ", use the following parameter", same comment as above. Agreed. I propose we say that the client does this. > Best Regards, > Meral > --- > Meral Shirazipour > Ericsson > Research > www.ericsson.com Thanks again, -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Last Call review of draft-ietf-oauth-saml2-bearer-21
Thanks for your review, Tom. I've added the working group to this thread so they're aware of your comment. > -Original Message- > From: Tom Taylor [mailto:tom.taylor.s...@gmail.com] > Sent: Sunday, September 28, 2014 8:33 PM > To: ops-...@ietf.org; draft-ietf-oauth-saml2-bearer@tools.ietf.org > Subject: Last Call review of draft-ietf-oauth-saml2-bearer-21 > > I have reviewed this document as part of the Operational directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the operational area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments. > > Tom Taylor > > Summary: Process issue: IDnits complains of a normative reference to > Informational document RFC 6755. This was NOT noted in the Last Call > announcement (but was noted in the Shepherd writeup). No operational issue > identified beyond what is already covered by the Interoperability > Considerations > section. 6755 defines a registry that this specification uses. > Editorial Nits: > > S2.2: The paragraph before the actual example uses terminology inconsistent > with RFC 6749: > > s/authorization code grant/authorization grant/ Actually, RFC 6749 uses both terms. Authorization grant is the generic term. Authorization Code Grant (defined in Section 4.1 of 6749) is a specific kind of authorization grant. Thanks again, -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-27: (with COMMENT)
Thanks for your review, Ted. I'm adding the working group to the thread so they're aware of your comments. > -Original Message- > From: Ted Lemon [mailto:ted.le...@nominum.com] > Sent: Thursday, October 02, 2014 6:58 AM > To: The IESG > Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web- > to...@tools.ietf.org > Subject: Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-27: > (with COMMENT) > > Ted Lemon has entered the following ballot position for > draft-ietf-oauth-json-web-token-27: No Objection > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this introductory > paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ > > > > -- > COMMENT: > -- > >The suggested pronunciation of JWT is the same as the English word >"jot". > > I would have gone with "jute". :) Also, this doesn't belong in the > abstract. It appears to have crept in as a result of cutting and pasting the > introduction into the abstract. You're not the first person with knowledge of Welsh to make the same comment. :-) (And this is a Jones responding...) I'll plan to remove the sentence from the abstract. > Is there any reason not to just require this: > >While syntactically the signing and encryption operations for Nested >JWTs may be applied in any order, normally senders should sign the >message and then encrypt the result (thus encrypting the signature). >This prevents attacks in which the signature is stripped, leaving >just an encrypted message, as well as providing privacy for the >signer. Furthermore, signatures over encrypted text are not >considered valid in many jurisdictions. > > When does it make sense not to do it this way? Sometimes authenticated encryption alone is good enough without requiring a signature. Different applications will have different requirements. So while this section discussion the applicable considerations, the working group felt that it was going too far to make this prescriptive. Thanks again, -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)
Thanks for your review, Stephen. I've added the working group to the thread so they're aware of your comments. > -Original Message- > From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] > Sent: Thursday, October 02, 2014 5:03 AM > To: The IESG > Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web- > to...@tools.ietf.org > Subject: Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: > (with > DISCUSS and COMMENT) > > Stephen Farrell has entered the following ballot position for > draft-ietf-oauth-json-web-token-27: Discuss > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this introductory > paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ > > > > -- > DISCUSS: > -- > > > (1) 4.1.1 and elsewhere you say case-sensitive: the same thing I raised wrt > DNS > names for another JOSE spec - do you need to say those SHOULD be > [upper|lower]cased when used in these? I believe that somewhere we should say that if case-insensitive values, such as DNS names, are used when constructing "kid" values, that the application doing so needs to define a convention on the canonical case to use for the case-insensitive portions, such as lowercasing them. > (2) Section 8: Why is "none" MTI? That seems both broken and going in the > oppostite direction from other WGs and so should be explicitly jusified I > think. (If > a good enough justification exists that is.) It is MTI because there are several existing applications of JWTs in which both unsigned and signed representations of the JWTs are requirements. These include draft-ietf-oauth-token-exchange, draft-hunt-oauth-v2-user-a4c, and OpenID Connect. This is a pretty common pattern where you sign something if the recipient cares who made the statements and where you don't have to sign it either if the recipient doesn't care who made the statements or if it can tell from another secured aspect of the application protocol (typically through the use of TLS) who made the statements. In the TLS case, the server authentication step makes a signature step unnecessary, so an Unsecured JWT is fine there. > (3) Section 12: another way to handle privacy is to not include sensitive > data - I > think you ought mention that as a bit of thought along those lines can be much > simpler than putting in place the key management to handle thoughtlessly > included PII. We can include a discussion of that point, but sometimes the very point of a JWT is to securely deliver PII from a verifiable party to an intended party with appropriate rights to receive it. > -- > COMMENT: > -- > > > - abstract: 2nd sentence isn't needed here, in intro would be fine. I don't know - I think it's a big deal that the claims can be digitally signed or MACed and/or encrypted. That's the reason we have JWTs, rather than just JSON. > - 4.1.7: maybe worth adding that jti+iss being unique enough is not > sufficient and > jti alone has to meet that need. In > X.509 the issuer/serial has the equivalent property so someone might assume > sequential jti values starting at 0 are ok. Makes sense to add a warning of some kind along these lines. I think I know the reasons you say that, but can you expand on that thought a bit before I take a stab on writing this up? For instance, while normally true, I don't think your observation is true if a relying party will only accept tokens from a single issuer. > - section 6: yuk > > - again I think the secdir comments are being handled by Kathleen and the > authors. Again, this is there because multiple applications asked for the ability to represent content that is optionally signed, sometimes securing it another way, such as with TLS. JWTs are used specific application protocol contexts - not in isolation. Thanks again, -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
