Subject: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-token-exchange-16: (with DISCUSS and COMMENT)

From: Alissa Cooper <[email-masked]>
Date: Tue, 20 Nov 2018 11:50:43 -0800

Alissa Cooper has entered the following ballot position for
draft-ietf-oauth-token-exchange-16: 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 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?

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

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?

---

From: George Fletcher <[email-masked]>
Date: Tue, 20 Nov 2018 15:08:41 -0500

In regards to the comment on section 4.1, it depends on the 
authorization policy and the deployment architecture. I don't believe 
there is a single solution that will work with all deployments.

It may be worth calling out that exposure of the entire delegation chain 
can leak information and that care should be taken to ensure the entity 
receiving the token with this information is in fact authorized to 
receive it.

On 11/20/18 2:50 PM, Alissa Cooper wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 28 Nov 2018 11:38:12 -0700

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

> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/

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.

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.

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