Alissa, Having not heard anything more on the issue, I went ahead and made those changes to the Privacy Consideration section. I believe they address the question/concern in your DISCUSS ballot. As such, I'd respectfully request that you review the changes and clear the discuss.
Thank you, Brian On Wed, Nov 28, 2018 at 1:38 PM Brian Campbell <bcampb...@pingidentity.com> wrote: > Thank you, Alissa, for the review. Please see below for inline > comments/responses and note that this is also my response to your last > message on the related thread at > https://mailarchive.ietf.org/arch/msg/oauth/MKqEIsb8TJCFUNl3vF-bB38nWv4 > > > On Tue, Nov 20, 2018 at 12:50 PM Alissa Cooper <ali...@cooperw.in> wrote: > >> Alissa Cooper has entered the following ballot position for >> draft-ietf-oauth-token-exchange-16: Discuss >> >> Please refer to https://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: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Section 6: The requirements around confidentiality here are weaker than >> in both >> RFC 7519 Sec. 12 and RFC 6749 Sec. 10.8. Why? >> > > I think the why of it is some unintentional drift in the language along > with my general reluctance in using the 2119 words out of a fear of > overusing them (which I'm admittedly inconsistent about but it certainly > manifested itself in this text). > > They should all say basically the same thing, which was really the intent, > if the actual wording didn't end up that way. > > I think that changing a few of the little shoulds to big MUSTs or SHOULDs > would bring the requirements around confidentiality here in line with RFC > 7519 Sec. 12 and RFC 6749 Sec. 10.8.. That updated text would be as > follows. Would this address your question/concern? > > Tokens employed in the context of the functionality described herein > may contain privacy-sensitive information and, to prevent disclosure > of such information to unintended parties, MUST only be transmitted > over encrypted channels, such as Transport Layer Security (TLS). In > cases where it is desirable to prevent disclosure of certain > information to the client, the token MUST be encrypted to its > intended recipient. Deployments SHOULD determine the minimally > necessary amount of data and only include such information in issued > tokens. In some cases, data minimization may include representing > only an anonymous or pseudonymous user. > > > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Section 3: >> >> If I understand this correctly: >> >> "The distinction between an access token and a JWT is subtle." >> >> I think it would be clearer if it said: >> >> "The distinction between an access token type and a JWT token type is >> subtle." >> > > In that sentence and paragraph I'm really meaning to talk about the things > themselves (access tokens and JWTs) rather than the type, which is more > like a way of naming those things. I don't think it's necessarily wrong > either way but my intention in writing is better reflected in the current > text. Furthermore, when the acronym in "JWT token" is expanded you get > "JSON Web Token token", which is something I'd like to avoid having in the > document. > > > >> Section 4.1: >> >> What is the value of maintaining the whole delegation chain rather than >> expressing just the most recent delegation? Doesn't it potentially expose >> information about past exchanges unnecessarily? >> > > There's value, in some situations, to being able to see/track the whole > delegation chain - primarily for auditing and troubleshooting type purposes > and typically when the parties in the chain are under the same domain of > organizational control where allowing that information to be available > isn't a concern but rather a benefit. > > And, of course, there's no requirement that the whole delegation chain be > maintained. The syntax and structure of the claim allows for the info to be > represented when appropriate but doesn't mean that it has to be. > > > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
