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

[Ludwig Seitz <[e-mail]>]

Thank you Jim,

I'll upload a new version as soon as we have resolved my questions below.

/Ludwig

On 30/01/2019 07:01, Jim Schaad wrote:
> 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.

That text just describes how it is in OAuth 2.0 (where refresh tokens 
are strings), since we didn't see the need to specify the use of refresh 
tokens in ACE, we didn't mention them further. If we had we would 
certainly have defined them to be binary.

> 
>> 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

There is text in the draft according to the suggestion above in section 
5.8.1 "The Authorization Information Endpoint". Should that text be 
moved to security considerations?

> 
> 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.
>

Right. I'll add some security considerations on that.


> ****** IANA Section Issues
> 
> 1.  None of the new registries appear to have any guidance for the DEs to
> use when approving items.

Is it acceptable to add a single guidance section for all of the new 
registries, or does it need to be separate for each of them?

> 
> 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.
> 
Would "ACE Authorization Server Discovery Hints" be better?

> 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".
> 
Done. Actually quite some changes were required to align all of the 
mappings sections with the OAuth registry names.

> 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.
> 
It's initially empty, since draft-ieft-ace-oauth-authz doesn't define a 
profile. However the DTLS and OSCORE profile will provide the two 
initial entries. I added a sentence to that effect in the IANA section.

> 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.
Fixed.

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone [phone]