Subject: [Ace] I-D Action: draft-ietf-ace-oauth-authz-27.txt

From: [email-masked]
Date: Wed, 20 Nov 2019 18:11:46 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF.

        Title           : Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)
        Authors         : Ludwig Seitz
                          Goeran Selander
                          Erik Wahlstroem
                          Samuel Erdtman
                          Hannes Tschofenig
	Filename        : draft-ietf-ace-oauth-authz-27.txt
	Pages           : 86
	Date            : 2019-11-20

Abstract:
   This specification defines a framework for authentication and
   authorization in Internet of Things (IoT) environments called ACE-
   OAuth.  The framework is based on a set of building blocks including
   OAuth 2.0 and CoAP, thus transforming a well-known and widely used
   authorization solution into a form suitable for IoT devices.
   Existing specifications are used where possible, but extensions are
   added and profiles are defined to better serve the IoT use cases.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-27
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-27

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-27

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 21 Nov 2019 03:16:03 +0100

Hello ACE,

turns out -26 didn't cover one of the items in Ben's review, namely the 
question of using Client introspection to determine token expiration as 
a lower bound for key expiration. Since the whole issue of Client 
introspection was contentious between OAuth experts, we decided to 
remove the text describing that option.  This still leaves us with the 
two other options, so the problem is still covered.

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 25 Nov 2019 15:04:11 -0800

Hi Ludwig,

> two other options, so the problem is still covered.

Thanks for all the updates!  I'm just about ready to push the "request Last
Call" button, but wanted to check one thing first:

Section 5.6.3 seems to limit the error responses to 4.00 and 4.01, but
Section 5.8.2 also talks about 4.03 and 4.05.  I noticed because I was
checking Section 5.1.1's note about "unauthorized_client" error response against the
various options in 5.8.2, to see if we're internally consistent about when
we say to send errors vs. AS request creation hints.  My recollection is
that we can have all three of a response code, error response (e.g.,
"unauthorized_client"), and (our custom format of) response payload present
in the same response, so any potential conflict would be limited to just
the response code, but please correct me if I'm wrong about that.

Also, a few nits that could be treated as LC comments:

There's a stray 'W' in Figure 7

In Section 6.8: s/obsole/obsolete/, and s/profile/ace_profile/

In Section 8.16 we removed the entire "Specifications are required for the
standards track range of point assignment[...]" bullet point.  I think that
only the first two sentences of that bullet point were redundant with RFC
8126, and the last two ("Specifications are needed for the first-come,
first-serve range if they are expected [...]") reflected new requirements.

Thanks,

Ben

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 27 Nov 2019 15:31:16 +0000

Hi Ben,

replies inline.

/Ludwig
________________________________________
From: Benjamin Kaduk <[email-masked]>
Sent: Tuesday, November 26, 2019 12:04 AM
To: Ludwig Seitz
Cc: [email-masked]
Subject: Re: [Ace] I-D Action: draft-ietf-ace-oauth-authz-27.txt

Hi Ludwig,

[LS] Section 5.6.3 describes the interaction with the token endpoint at the AS. There we mirrored the behaviour of OAuth error responses.
Section 5.8.2 describes the interaction with the newly defined authz-info endpoint at the RS. We decided that this warranted more detailed error responses, so that a client gets some hint on what went wrong when an access token is rejected by the RS.
This is why we have added the  4.03 and 4.05 messages.
Section 5.1.1 describes an access request to a resource at the RS (other than the authz-info endpoint) and has yet another different error behaviour.
For the token endpoint (5.6.3), the response code is part of the HTTP/CoAP header, while the "error" parameter (with values such as e.g. "unauthorized_client") is part of the payload in certain error responses (which may also contain "error_description" and "error_uri"), this is just mirroring behaviour of OAuth.
For the authz-info endpoint (5.8.2) no such parameters are specified in the document (i.e. it just uses the response codes).
Does this clarify the issue?

[LS] Does the " LC comments" part mean I should wait with updating the draft?

/Ludwig

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 28 Nov 2019 22:29:59 -0800

> /Ludwig

It does; thanks for putting the pieces into the proper context for me.

> [LS] Does the " LC comments" part mean I should wait with updating the draft?

It means you're free to wait, yes.  (If you want to update anyway that's
also fine.)

-Ben