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