[Ace] Shepard review for draft-ietf-ace-oauth-authz

[Jim Schaad <[e-mail]>]

1. Update the reference from RFC 5246 to RFC 8446 in all locations



Items that don't appear to be resolved:

* Section 3.1 - Refresh Token - I don't think that refresh tokens are going
to be strings because binary is more efficient.  
	 Unless you are going to say that this is not OAuth 2.0, then a
refresh token is still a text string.

*  I don't see any text that is addressing this.

> On 22/10/2018 21:09, Jim Schaad wrote:
> > * Section 5.8.2 - If the RS is going to do introspection, can it send
some
> > type of "Server Busy - try again in xxx" while it does the introspection
> > rather than just doing an ack of the request and possibly waiting a long
> > time?
> 
> This is probably transport protocol specific, and we were asked not to 
> link the framework to a specific protocol, thus I don't know if we can 
> provide guidance here.

I think it would be okay to say something like "some transport protocols
may provide a way to indicate that the server is busy and the client should
retry after an interval; this type of status update would be appropriate
while the server is waiting for an introspection response".  Which does
provide guidance, but in a non-normative fashion that does not require or
prohibit any given transport protocol.

*  I don't see anything that I think addresses this issue.  I would expect
it to be a security consideration

Comments on protection of CWT/Token:  I am wondering if there needs to be
any comments on how a CWT is going to be protected.  While it is ok to use
either a symmetric key or a direct key agreement operation for a single
recipient without forcing a signature operation to occur.  If the token is
going to be targeted a single audience hosted on multiple RSs then a
signature operation would be required for the purposes of authentication.  

****** IANA Section Issues

1.  None of the new registries appear to have any guidance for the DEs to
use when approving items.

2.  The title of the registry "ACE Authorization Server Information" is not
really descriptive of what is in the registry.   It makes sense in the text
but not as a stand along title.  Something along the lines of "ACE
Authorization Server Request Creation Hints" seems to be closer to a solid
identification.

3.  The mapping registries should use the OAuth registry name as a prefix.
Thus "OAuth Access Token Types" and "OAuth Access Token Type CBOR Mappings".

4.  What is the initial registrations that need to occur for the "ACE
Profile" registry.  If there are none then this needs to be stated.

5. For the CBOR Web Token Claims - how many of these should have the JWT
Claim name filled in?  It would seem that all of them should.  If not a
comment about this is needed.


Jim