Re: [OAUTH-WG] WGLC for draft-ietf-oauth-token-exchange-08

Brian Campbell <> Fri, 30 June 2017 20:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0575D12E957 for <>; Fri, 30 Jun 2017 13:08:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZnXKokwDEIAq for <>; Fri, 30 Jun 2017 13:08:57 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 332A4128BC8 for <>; Fri, 30 Jun 2017 13:08:54 -0700 (PDT)
Received: by with SMTP id j186so68267704pge.2 for <>; Fri, 30 Jun 2017 13:08:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zsb9WlSk330L/jCDD6RIp0/hXuUSGDt5ogNB5GYqMsg=; b=NZi9kC5FndJl3YN9DGaUdZHAcggUN78Z8JwC7m+6mOGGZXINahErhk3Sr8IZjf38QR 3fmujJaIgX85XDDVzuXlaRUkJi/uUfuZyLN8WIlGDbv6JqB+8U2PT3xFVSTSzFuSBdos 9Wai1ZkgRw56JcjbyjTtprF9R2IgA81U8N118=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zsb9WlSk330L/jCDD6RIp0/hXuUSGDt5ogNB5GYqMsg=; b=SJ55XqeGCLyM3HyQOJENT7q5YUBgZqaCspfMj4VHFGZlNEEwvo2xta4kXeB63nWLvu kadIa4q5j5oz2nooXZmu2ZMCAF2nKyKAXnbV6G6deQoGmKWWgwAn1Lybf47CdgZ/HdQg octaR3Q0yozf2iySHt0PEVu8+CAT3i9H0H8+n1kRP/BA1YqhhRRy4CSbHWEmqy3N6lqB LmOkObaK3n3Pt0pDGBMd7W3S7XJ4/g2ysV7BVdx7+jUAl58nzh6u+MFb9npZ2yJ0yRmB jAiY7kfA0J5qcu2iZ3DCbX8BL3/Dh5rH0GVGG97jZtdMfePLFLLcGJDeu0VkE58wPDwG tw5Q==
X-Gm-Message-State: AKS2vOypEzmeHas9CVXLjiDgjyfeEs0Pa4ZRTfgmlJyqNWdHrHLyIMU9 Med5xTB0N0wgF79fRVrvrAKiNM4GZ2lSr9UBav1xXqUVsqXOkkqn137/4p1c+YlLMYmr53MmsA2 D0dDxt0U=
X-Received: by with SMTP id j11mr24594443pfe.18.1498853333683; Fri, 30 Jun 2017 13:08:53 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 30 Jun 2017 13:08:23 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Brian Campbell <>
Date: Fri, 30 Jun 2017 14:08:23 -0600
Message-ID: <>
To: Rifaat Shekh-Yusef <>
Cc: oauth <>
Content-Type: multipart/alternative; boundary="94eb2c14fd80867029055332fc90"
Archived-At: <>
Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-token-exchange-08
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Jun 2017 20:08:59 -0000

Thanks for the review, Rifaat. Replies are inline below...

On Mon, Jun 26, 2017 at 6:40 AM, Rifaat Shekh-Yusef <>

> Hi (as individual),
> I have reviewed this version of the document and I have the following
> comments/questions:
> Section 2.1, page 8, last paragraph:
>    "In the absence of one-time-use or other semantics specific to the
>     token type, the act of performing a token exchange has no impact on
>     the validity of the subject token or actor token."
> Would the validity of the new issued token be impacted later on by the
> validity of the subject or actor tokens?

No, the intent is that the tokens presented for exchange need to be valid
at the time of exchange but after that the validity of the issued token is
decoupled from, and has no dependency on, the subject or actor tokens.

Do you feel that the doc should state this more explicitly? If so, a
sentence like this could be added following the text you quoted,
"Furthermore, the validity of the subject token or actor token have no
impact on the validity of the issued token after the exchange has

> Section 2.2.2, page 10, second paragraph:
>   "If the authorization server is unwilling or unable to issue a token
>    for all the target services indicated by the "resource" or "audience"
>    parameters, the "invalid_target" error code MAY be used in the error
>    response."
> Can you please elaborate on why the above text is using "MAY" for the use
> of "invalid_target" in this case?
To be honest, I don't recall exactly why I went with "MAY" there. And on
seeing your question and reading it again, that feels like it should be
stronger than "MAY".

Should that "MAY" be changed to a "SHOULD"? Or even a "MUST"?

> Section 4.1, page 14, second paragraph:
>   "However, claims within the "act" claim pertain only to the identity
>    of the actor and are not relevant to the validity of the containing
>    JWT in the same manner as the top-level claims.  Consequently, claims
>    such as "exp", "nbf", and "aud" are not meaningful when used within
>    an "act" claim, and therefore should not be used."
> If the "exp", "nbf", and "aud" claims are not meaningful inside the "act"
> claim, why is the sentence stating that it "should not be used"?
> Would it not be more appropriate to state that it "must not be used"
> instead?
My thinking here is that saying, 'such as "exp", "nbf", and "aud" claims'
is more of a general statement of guidance rather than a fully inclusive of
list of claims that aren't meaningful inside the 'act' claim. And a full
list isn't really feasible given that new claims can be defined in the
future.  So the use of "should" seemed more appropriate in that context
rather than "must" or any RFC 2119 words. We can discuss changing that
somehow, if you and/or other WG members think a change is needed? But that
was my line of reasoning behind the current text.

>  Rifaat
> On Fri, Jun 2, 2017 at 3:05 PM, Rifaat Shekh-Yusef <>
> wrote:
>> All,
>> We are starting a WGLC on the Token Exchange document:
>> Please, review the document and provide feedback on any issues you see
>> with the document.
>> The WGLC will end in two weeks, on June 17, 2017.
>> Regards,
>>  Rifaat and Hannes
> _______________________________________________
> OAuth mailing list

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