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

Cigdem Sengul <> Tue, 18 October 2016 08:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7BA36129997 for <>; Tue, 18 Oct 2016 01:34:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 RkJCkhqReGrl for <>; Tue, 18 Oct 2016 01:34:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 882C0129991 for <>; Tue, 18 Oct 2016 01:34:31 -0700 (PDT)
Received: by with SMTP id f6so148804682qtd.2 for <>; Tue, 18 Oct 2016 01:34:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=o542RSINtbLaiXZl6BiR9LPrGnCeYmPwpm4FVnppWeI=; b=wj2WbAxxzt3jt1AX/XOvvSyZfvFo+VwP7snUOW/bahIP+P8eTab+tDSglZNNgoCtJK anmBFARL3MGVX+7uASZeYTLmGa6B9MtSK7TChc+snvAPckj/BoZfe1ObMUBtN3Ji5rat nYWmzp5262pwgipGgbbqMoQShicxPkkMZQ/UjzH5iaKZxdR5+ed9/AufjbQiIgBrjcZ1 p4dEJDoUTKI8P5lNsPHVdUPG1H1Gcs3+TRaza7pkUxDu7js1kQaRKNfWODrpdeykm8Ex HZNOlKvGC5q1KA7jni31hvQe4YLVwmKiI+I3JBw8WjIPj+JVd0q6ZvQQlEx+YxYKa8VQ leKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=o542RSINtbLaiXZl6BiR9LPrGnCeYmPwpm4FVnppWeI=; b=HNRyT/6OWNUaCiY0fM+cIhoLf4+LknG73DM8iuo17z4OF0biH4h8IZIPoMJ3oOMLsa 4cNk6evXutx0aP1Uabv82FFQR1thvA6KnSC4LWf/Xthh/EsOrUshITqpFJKQBLES6MQf uwl7LrqOWi0Qzj4T0+V/FcNbPLePe2Kovc+NNELpLi3qx9okJgLoES1GpuNKkj/YwEPs 3NR/FcHppBzI2OzSzDX4HteMc58bcZs9iGee+H4xoiklagOK0ih+ZDk37oRVZ0uJXX3+ 8OJputCalyzUFKiyfYaMWXovkmk663yWsxOzK3Y32Yo2MTtv3rQKNlrejUV+HRPmcxnl 28iA==
X-Gm-Message-State: AA6/9RkSawb17GA7JhsvN027H/yqaZAj+4AjHi4y5/raYeIuyrbdvWkxT0vfRMALGd5yyxvg6X9HYIPmg//E7A==
X-Received: by with SMTP id r131mr10501606wmb.2.1476779670328; Tue, 18 Oct 2016 01:34:30 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 18 Oct 2016 01:34:29 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Cigdem Sengul <>
Date: Tue, 18 Oct 2016 09:34:29 +0100
Message-ID: <>
To: "" <>
Content-Type: multipart/alternative; boundary="001a11471ae4a95bfb053f1f8f52"
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, 18 Oct 2016 08:34:34 -0000

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

Minor typos:

Page 5/Section 3.1/ OAuth2.0: "The RS makes a POST request to /introspect
on the AS and

      receives information about the access token contain in the

      ==> Remove “contain”?

Page 8/Section 3.2: "and also to support security for CoAP over

   different transport in a uniform way,”

      ==> “over a different transport”

Page 8/Section 4: " RFC 7744 <>
[RFC7744 <>] describes many

   IoT use cases but there two preferred grant types”

     ==>"there are two"

Page 9/Section 4: "the OAuth client itself is constraint.  In such a “

        ==> “the OAuth client itself is constrained.”

Page 9/Section 4: "which is often accomplished using

   an commissioning tool.”

    ==>  “a commissioning tool”

Page 10/Section 4/Access Token Response: "More

      information about these parameters can be found in in Section
6.4 <>.”

    ==> Remove the second “in”

Page 16/Section 6.2/AS-to-Client Response: "The content of the
successful reply MUST be encoded as CBOR map,

   containing paramters as specified "

    ==> “paramters” typo

Page 20/Figure 8/caption: "Confirmation paramter”

      ==> typo in “parameter”

Page 24/Just below Figure 14: "The client token is a COSE_Encrytped object”

    ==> typo in “COSE_Encrytped”

Page 26/Section 8: "same way as specified for the "cnf" parameter in section

   Section 6.4.5

==> Remove duplicate “section”

Page 29/10.1/cnf description: "Description: Key to use to prove the
right to use an access token,

      as defined in [RFC7800 <>].”

==> Drop the first “to use”. “Key to prove the right to use an access token”?

Page 30/10.1/aud description: “Description: reference to"

==> “r” capital in reference

Page 30/10.1/profile description: “The communication and communication
security profile”

==> “communication” duplicate.

Page 30/10.2/cnf: "Description: Key to use to prove the right to use”

==> Drop the first “to use”

Page 32/10.6.1/Profile description: “over view”

==> “overview"

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 seems to be the case according to Page 9:

"Established keying material between the AS and the RS allows

   the AS to apply cryptographic protection to the access token to
   ensure that its content cannot be modified, and if needed, that the
   content is confidentiality protected.”

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.

Page 15/Figure 4:

Question: Is the grant_type in this example “client_credentials” or “password”?

Page 17/Figure 5:

Question: Shouldn’t the example contain the “profile” parameter, which
was “REQUIRED” in the response in the previous paragraphs.

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.

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

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”?

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?

 Hope this helps,
--Cigdem Sengul
Senior Researcher

On Wed, Oct 12, 2016 at 12:37 PM, Ludwig Seitz <> wrote:

> Hello ACE,
> we have uploaded a new version of our draft, addressing mainly the review
> comments from Renzo and adding a number of clarifications about the /token,
> /introspect and /authz-info endpoints.
> Please review this version and send us comments, if we get enough feeback
> we might be able to produce another version before the cut-off.
> Regards,
> Ludwig
> -------- Forwarded Message --------
> Subject: New Version Notification for draft-ietf-ace-oauth-authz-03.txt
> Date: Wed, 12 Oct 2016 04:35:28 -0700
> From:
> To: Ludwig Seitz <>, Erik Wahlstroem <
>>, Goeran Selander <>,
> Samuel Erdtman <>, Hannes Tschofenig <
> A new version of I-D, draft-ietf-ace-oauth-authz-03.txt
> has been successfully submitted by Ludwig Seitz and posted to the
> IETF repository.
> Name:           draft-ietf-ace-oauth-authz
> Revision:       03
> Title:          Authentication and Authorization for Constrained
> Environments (ACE)
> Document date:  2016-10-12
> Group:          ace
> Pages:          56
> URL:
> thz-03.txt
> Status:
> doc/draft-ietf-ace-oauth-authz/
> Htmlized:
> Diff:
> Abstract:
>    This specification defines a framework for authentication and
>    authorization in Internet of Things (IoT) environments.  The
>    framework is based on a set of building blocks including OAuth 2.0
>    and CoAP, thus making a well-known and widely used authorization
>    solution suitable for IoT devices.  Existing specifications are used
>    where possible, but where the constraints of IoT devices require it,
>    extensions are added and profiles are defined.
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at
> The IETF Secretariat
> _______________________________________________
> Ace mailing list