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

[Kathleen Moriarty <[e-mail]>]

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

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