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 _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace