Responding to the DISCUSS below…
-----Original Message----- From: Alissa Cooper [mailto:ali...@cooperw.in] Sent: Wednesday, October 01, 2014 12:25 PM To: The IESG Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web-to...@tools.ietf.org 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.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
