DATE 2 March 2019 - version -21
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.
Changes are expected over time. This version is dated 24 February 2012.
(1) Is should be a Proposed Standard and that is reflected in the
meta information.
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:
Technical Summary
This document describes a framework for the use of OAuth 2.0
in a constrained environment. The document is mainly targeted
at the protocols defined for CoAP, but other protocols can
be used as well. The framework defines the fields and
symmantics needed for doing authorization and authenticiation
of a client.
Working Group Summary
The concesus on the document wa generally very solid. There
were some issues that arose between the ACE and OAuth working
groups over a couple of issues. These issues appear to have
been resolved.
Document Quality
There have been at least four different groups who have
announced an implementation at some level of the specification.
While two of those implementations share a certain amount of
common code, there are two implementations which have done
interop tests at various times which do not share any code
based on this document.
The scope and issues of trying to deal with some of the
OAuth 2.0 documents can be challenging at times. While
it is believed that a good job has been done, there are
some potential areas where different people might end up
doing new things.
Personnel
Jim Schaad is the Document Shepherd. Ben Kaduk is the
responsible AD.
(3) I have done a detailed read a number of times during the WGLC
process and while shepherding to make sure all WGLC comments were
addressed. Additionally, I have done an implementation of the document
during development.
(4) Between the implentations of the framework that we have and the
healthy discussions during the WGLC, I am confident that there has
been quite broad review of the document.
(5) No broader review should be needed. During the process there has
been significant review from the OAuth working group.
(6) I have no issues with this specific document. I do have a problem
with how the registries have been setup in OAuth, but that is not
germane to this document.
(7) All authors have indicated that they do no know of any additional IPR
that needs to be disclosed.
Ludwig 2/25/19
Goren 2/25/19
Erdtman 2/25/19
Hannes 2/27/19
(8) There is an IPR disclosure on this document. During the shepards review, I
specifically requested if there were any concerns about this IPR and none were
raised.
(9) The set of people that have contributed probably represent about a dozen
individuals in the WG.
(10) There has been no extreme discontent expressed during the discussions.
(11) No ID nits are called out.
(12) The only formal review needed is for a new media type.
The media type request for application/ace+cbor was mailed 23 Feb 2019.
(13) All references are tagged and reasonable.
(14) All of the normative documents which are in process are at the
same stage of development and thus should not cause any issues.
(15) There are no downward normative references.
(16) This document represents the first iteration. It profiles and extends
some of the OAuth documents, but this is not done by modifications of the
documents themselves.
(17) It was somewhat painful. I looked at all items that were defined
and should be registered to make sure that they existed in the IANA
considerations. I compared the registrations of items with the required
templates or columns in the IANA registries. A detailed walk of the
new registries along with reasonable behavior was examined.
(18) The following new IANA registries are created:
ACE Authorization Server Request Creation Hints -
Contains a set of attributes to be returned from a resource server
that can be used by a client when building the request to the
authorization server. There is not currently an equivalent registry
for OAuth so it is not clear that an OAuth person is going to be
extremely useful. Some implementation experience would probably
be useful, but is definitely not required.
OAuth Error Code CBOR Mappings -
Contains a mapping of errors that can be returned in OAuth. No
special expertise should be required for the experts.
OAuth Grant Type CBOR Mappings -
Contains a mapping of grant types from the OAuth registry to a
CBOR integer. No special expertise should be required for the
experts.
OAuth Access Token Type CBOR Mapping -
Contains a mapping of token types from the OAuth registry to
a CBOR integer. No special expertise should be required for
the experts.
ACE Profile -
Contains the set of ACE profiles that use the framework.
The experts should have a solid working knowledge of the framework
as they need to be able to evaluate any new profile against the
framework to make sure that all of the conditions outlined are
fulfilled.
OAuth Parameters CBOR Mapping -
Contains the set of mappings from OAuth parameters to integer
values. No special expertise should be required for the
experts.
OAuth Token Introspection Response CBOR Mappings -
Contains the mapping of response parameters from the OAuth
registry to a CBOR integer and type. No special expertise should
be required for the experts.
List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
(19) No automated checks were done.