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

[Samuel Erdtman <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]> 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: [e-mail]
>> To: Ludwig Seitz <[e-mail]>, Erik Wahlstroem <
>> [e-mail]>, Goeran Selander <[e-mail]>,
>> Samuel Erdtman <[e-mail]>, Hannes Tschofenig <
>> [e-mail]>
>>
>>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ace
>>
>>
>
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace
>
>