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.

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
      response”.

      ==> 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 <https://tools.ietf.org/html/rfc7744>
[RFC7744 <https://tools.ietf.org/html/rfc7744>] describes many
different

   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 <https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-03#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
<https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-03#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 <https://tools.ietf.org/html/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
transport.


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
Nominet

On Wed, Oct 12, 2016 at 12:37 PM, Ludwig Seitz <lud...@sics.se> 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: internet-dra...@ietf.org
> To: Ludwig Seitz <lud...@sics.se>, Erik Wahlstroem <
> e...@wahlstromtekniska.se>, Goeran Selander <goran.selan...@ericsson.com>,
> Samuel Erdtman <erdt...@spotify.com>, Hannes Tschofenig <
> hannes.tschofe...@arm.com>
>
>
> 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: https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-au
> thz-03.txt
> Status:         https://datatracker.ietf.org/
> doc/draft-ietf-ace-oauth-authz/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-03
> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-03
>
> 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 tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>
>
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Reply via email to