Re: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS)

[Mike Jones <[e-mail]>]

These resolutions have been incorporated in the -28 draft.  Thanks again for your review.

                                                            -- Mike

From: Kathleen Moriarty [mailto:[e-mail]]
Sent: Thursday, October 02, 2014 8:21 AM
To: Mike Jones
Cc: Alissa Cooper; The IESG; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: Alissa Cooper's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS)



On Thu, Oct 2, 2014 at 11:14 AM, Mike Jones <[e-mail]<mailto:[e-mail]>> wrote:

Responding to the DISCUSS below…



-----Original Message-----
From: Alissa Cooper [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Wednesday, October 01, 2014 12:25 PM
To: The IESG
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Alissa Cooper's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS)



Alissa Cooper 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 12 ==



"A JWT may contain privacy-sensitive information.  When this is the

   case, measures must be taken to prevent disclosure of this

   information to unintended parties."



It seems to me that this should be a normative MUST, particularly in light of the fact that claims are being defined that are meant to directly identify users (e.g., sub) and other claims defined here or later could do so as well.



There seems to be debate whether a 2119 language should be used other than when describing protocol requirements.  Jim Schaad (the JOSE chair) believes that they shouldn’t and these documents have followed that convention.
With other documents, there is RFC2119 language used for security & privacy considerations.  At some point there was a trend to have a separate "Security Requirements" section from "Security Considerations", but I don't think there was any requirement for this, just a preference.  I agree that this should be a MUST, but with Stephen as well that you should discourage putting in privacy related information to begin with.



"One way to achieve this is to use

   an encrypted JWT.  Another way is to ensure that JWTs containing

   unencrypted privacy-sensitive information are only transmitted over

   encrypted channels or protocols, such as TLS."



Since sensitive JWTs should be protected from both intermediary observation and from being sent to unintended recipients, I would

suggest:



One way to achieve this is to use an encrypted JWT and authenticate the recipient. Another way is to ensure that JWTs containing unencrypted privacy-sensitive information are only transmitted over encrypted channels or protocols that also support endpoint authentication, such as TLS.



Thanks for this suggested language.  We can incorporate something like that.
OK, this makes sense and will feed into Pete's discuss on where TLS should be required.

Thanks!





--

Best regards,
Kathleen