On Thu, Oct 2, 2014 at 11:14 AM, Mike Jones <michael.jo...@microsoft.com> wrote:
> 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. > > 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
