These resolutions have been incorporated in the -28 draft. Thanks again for
your review.
-- Mike
From: Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com]
Sent: Thursday, October 02, 2014 8:21 AM
To: Mike Jones
Cc: Alissa Cooper; The IESG;
oauth-cha...@tools.ietf.org<mailto:oauth-cha...@tools.ietf.org>;
draft-ietf-oauth-json-web-to...@tools.ietf.org<mailto:draft-ietf-oauth-json-web-to...@tools.ietf.org>;
oauth@ietf.org<mailto:oauth@ietf.org>
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
<michael.jo...@microsoft.com<mailto:michael.jo...@microsoft.com>> wrote:
Responding to the DISCUSS below…
-----Original Message-----
From: Alissa Cooper [mailto:ali...@cooperw.in<mailto:ali...@cooperw.in>]
Sent: Wednesday, October 01, 2014 12:25 PM
To: The IESG
Cc: oauth-cha...@tools.ietf.org<mailto:oauth-cha...@tools.ietf.org>;
draft-ietf-oauth-json-web-to...@tools.ietf.org<mailto: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
