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

[Mike Jones <[e-mail]>]

Responding to the DISCUSS below…



-----Original Message-----
From: Alissa Cooper [mailto:[e-mail]]
Sent: Wednesday, October 01, 2014 12:25 PM
To: The IESG
Cc: [e-mail]; [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.



"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.