Re: [secdir] Security review of draft-ietf-oauth-token-exchange-14

[Brian Campbell <[e-mail]>]

Hi Hilarie,

I've published
<https://mailarchive.ietf.org/arch/msg/oauth/Dqlg3JQqhChHy83j4IwqhLeoR88> a
new draft -15 of OAuth Token Exchange
<https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-15>, which I
hope/believe addresses the comments you raised.
<https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-15>

Thanks again for the review,
Brian


On Mon, Aug 13, 2018 at 11:36 AM Brian Campbell <[e-mail]>
wrote:

>
> On Fri, Aug 10, 2018 at 3:26 PM Benjamin Kaduk <[e-mail]> wrote:
>
>> ...
>> With the disclaimer that I haven't read token-exchange recently and am
>> mostly going off my memory of the mailing list discussions, it seems like
>> the key consideration here is that token exchange allows you to convert a
>> token that may be opaque to you into one that has inspectable fields, and
>> those fields can be privacy sensitive.  So a JWT response should only be
>> given to a requestor that trusted to know such information; a lot of the
>> time, that has large overlap with being trusted to have the token in the
>> first place, but potentially there is some amount of non-overlap.
>>
>> The considerations from 7523 of course also apply, and sensitive
>> information should not be sent over unencrypted channels, but isn't the
>> above paragraph an aspect inherently new to token exchange?
>
>
> I don't think it's unique to token exchange. RFC 7523, for example,
> defines the use of a JWT as an authorization grant used to obtain an access
> token from a authorization server. Unless encrypted as a JWE, the JWT in
> that scenario has fields that are inspectable to the client. And an OAuth
> access token is considered opaque to the client but whether or not
> information in the token is actually accessible to a client is an
> implementation detail of the authorization server. The latter is true for
> OAuth in general and not just these more specialized exchanges.
>
> The idea behind maybe incorporating some text similar to (but adapted to
> the context) what's in the privacy considerations of RFC 7523
> <https://tools.ietf.org/html/rfc7523#section-7> is that the
> considerations are pretty much the same - use TLS in transit, minimize the
> amount of information in the token, encrypt the token if disclosure of its
> information to the client is a concern.
>
>
>
>
>

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