Thanks for reading and commenting. I have looked at the minor typos for now, see inline
Working draft can be found here https://github.com/LudwigSeitz/ace-oauth //Samuel On Tue, Oct 18, 2016 at 10:34 AM, Cigdem Sengul <[email protected]> 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. > > 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”? > > fixed > > Page 8/Section 3.2: "and also to support security for CoAP over > > different transport in a uniform way,” > > ==> “over a different transport” > > fixed > > 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" > > fixed > > Page 9/Section 4: "the OAuth client itself is constraint. In such a “ > > ==> “the OAuth client itself is constrained.” > > fixed > > Page 9/Section 4: "which is often accomplished using > > an commissioning tool.” > > ==> “a commissioning tool” > > fixed > > 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” > > fixed > > 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 > > fixed > > Page 20/Figure 8/caption: "Confirmation parameter” > > ==> typo in “parameter” > > fixed > > Page 24/Just below Figure 14: "The client token is a COSE_Encrytped object” > > ==> typo in “COSE_Encrytped” > > fixed > > 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” > > fixed > > 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”? > > fixed > > Page 30/10.1/aud description: “Description: reference to" > > ==> “r” capital in reference > > fixed > > Page 30/10.1/profile description: “The communication and communication > security profile” > > ==> “communication” duplicate. > > The profile will define both communication, e.g. COAP or HTTP, and communication security, e.g. DTLS or COSE. So it might be useful that this is called out > > Page 30/10.2/cnf: "Description: Key to use to prove the right to use” > > ==> Drop the first “to use” > > fixed > > Page 32/10.6.1/Profile description: “over view” > > ==> “overview" > > fixed > > > > 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 <[email protected]> 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: [email protected] >> To: Ludwig Seitz <[email protected]>, Erik Wahlstroem < >> [email protected]>, Goeran Selander <[email protected]>, >> Samuel Erdtman <[email protected]>, Hannes Tschofenig < >> [email protected]> >> >> >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/ace >> >> > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace > >
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
