Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-03.txt

Ludwig Seitz <> Tue, 25 October 2016 12:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 63AF4129532 for <>; Tue, 25 Oct 2016 05:58:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dDrAe3Th6Gv5 for <>; Tue, 25 Oct 2016 05:58:47 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DD93F12950F for <>; Tue, 25 Oct 2016 05:58:46 -0700 (PDT)
Received: by with SMTP id b75so210035546lfg.3 for <>; Tue, 25 Oct 2016 05:58:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=TStJeCEphYWcDLGbfPo3Z2SbqPsLJwvz3CYoXhw2a6E=; b=Xz+dRaonCBglY30osZvRWhHx0mfa8GWoFI5Nfy+BT5d/p49CxSjMhyptmK/OZsKf7g A7q7bS98zG9uMn9H0Jxi+HsIzgiffsmr+jBneBzOdc5EZ5/yt+r/Azlf6uJhfi3Mifnd 94VaJ5o6q4+bbEEmgBcBbuNgDHt0JpVZcNboJuybnGPItLbSzAlL4/lL8jmz5IJWTAFd RD301TLvWbTvob3h871ysGq/ek4Jm1vHOm/YIPKPGXCXIGDHDbpx2SN0EQF+xh+Z+fHs HNSeaZRshIVjD6wkx5iPaSRQAyxWFTiKNSpJc9xx6ixB4ZPoqw96AdQS+IvWxl+GKi57 aHAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=TStJeCEphYWcDLGbfPo3Z2SbqPsLJwvz3CYoXhw2a6E=; b=As9mGeVOKy9wV7s70S3/SgGoRM9exhEkMfzHm/aVJgJCqZsq49OKvJKwrDSm8apgD9 ZUWB3WiZBjYZR5IYq7yM8UdHjPYm8bmz5z6Cb+U6327yC7ntZ7671COPAVVxpUpfKg4+ PbXziDsbRklBkeMUQKfCSMGCNZs9brC3ivDmqGNbTmuZLZMso1dytvgdMXxDjnkpUzY3 xM5f2zD1p5xzNojPCarKoH3KA2OCUXcPxwJqBTUtdBz9+lPPWUETu6CvwSZEY+muSVqe FD7uvhwQlMuY4l0Tw1qZjiZuDR95f54P6wWYyyDEuPjTSGr6xg9I09UoH5e5y6iYondA MRjg==
X-Gm-Message-State: ABUngvehPa2GysycMtvjT6RgJjlnaj/ImxFTBalR7R1Kg+dqXRmFQp8ibbqatRvjvcfrg0d7
X-Received: by with SMTP id 6mr8521462lfi.64.1477400324188; Tue, 25 Oct 2016 05:58:44 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id s20sm3943688lfi.12.2016. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Oct 2016 05:58:43 -0700 (PDT)
References: <> <> <>
From: Ludwig Seitz <>
Message-ID: <>
Date: Tue, 25 Oct 2016 14:58:42 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms010507010108010506020107"
Archived-At: <>
Subject: Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-03.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Oct 2016 12:58:49 -0000

On 2016-10-18 10:34, Cigdem Sengul wrote:
> Hello Ludwig,
> Thanks for adding the new sections on requirements on profiles and the
> examples in the appendix are quite useful too.
> I list minor typos and request for clarification/consistency below. Hope
> it helps.

Hello Cigdem,

thank you very much for your review. I have addressed your issues in the 
draft and provided answers inline for your convenience.



> Requests for clarification:
> ====================
> Page 6/Access Token: "The access token is protected against
> modifications using a MAC or
> a digital signature, which is added by the AS”
> Question: Are access tokens also confidentiality protected e.g.,
> encrypted by the AS, to be consumed by RS?

It depends on the encoding of the token, with CWT you indeed have the 
possibility to encrypt the token.

Added text to clarify this.

> Page 11/Section 4/Token Introspection Response: "The AS can additionally
> return information that the RS needs to pass on to the client in the
> form of a client token. The latter is used to establish keys for mutual
> authentication between client and RS, when the client has no direct
> connectivity to the AS.”
> Question: The client still should have had an initial connectivity to
> the AS, and has acquired an initial access token, right? This seems to be what
> is described in Page 24.
Correct. Clarified this in section 7.4. and added a reference to this 
section in section 4.

> Page 15/Figure 4:
> Question: Is the grant_type in this example “client_credentials” or
> “password”?
The client_id and client_secret parameters can be used with any grant as 
specified in section 2.3.1. of the OAuth 2.0 RFC. This is indeed 
intended to be a client_credentials grant_type.
Do not confuse this with the "password" parameter of the
resource owner password credentials grant.

> Page 17/Figure 5:
> Question: Shouldn’t the example contain the “profile” parameter, which
> was “REQUIRED” in the response in the previous paragraphs.
Right, that was an oversight.

> Page 19/20/CoSE_Encrypted:
> Question: Is this confirmation parameter used when passing the key to
> the client as a response to POST to /token? Or is it used when passing
> client token through RS? From Page 24, it seems to be former.
Added a clarification as to how the confirmation parameter is used in 
section 6.4.5.

> Page 27/Section 8.1:
> "Profiles of this framework MAY define other methods for token
> transport. Implementations conforming to this framework MUST implement
> this method of token transportation.”
> Question: Do you mean “this framework” or “this draft”. Just want to be
> absolutely sure, that profiles MAY define other methods for token
> transport.
Added a clarification in the terminology section.

> Page 28/Section 9: "Using a single
> shared secret with multiple authorization server “
> Question: There is a type here. “Server” should be “servers” but
> shouldn’t this be “Resource servers”?
Yes are right, that was a textual error.

> Page 44/Appendix B: “Resource Server”
> Question: Is introspection option excluded here deliberately? “ The
> sentence: "Optionally: Check that the matching tokens are still valid
> (if this is possible.)” Is this the hint for the introspection?

No it is not, this was a simple oversight.

Ludwig Seitz, PhD   SICS Swedish ICT AB
Ideon Science Park, Building Beta 2
Scheelevägen 17, SE-223 70 Lund
Phone +46(0)70-349 92 51

The RISE institutes SP, Swedish ICT and Innventia are merging in order 
to create a unified institute sector and become a stronger innovation 
partner for businesses and society. At the end of the year we will 
change our name to RISE.