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

[Ludwig Seitz <[e-mail]>]

On 30/01/2019 19:23, Jim Schaad wrote:
> 
> 
>> -----Original Message----- From: Ludwig Seitz <[e-mail]> 
>> Sent: Wednesday, January 30, 2019 12:38 AM To: Jim Schaad
>> <[e-mail]>; draft-ietf-ace-oauth- [e-mail] Cc:
>> [e-mail] Subject: Re: Shepard review for
>> draft-ietf-ace-oauth-authz
>> 
>> 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.
> 
> That would be fine, but you actually do define a CBOR mapping tag for
> refresh tokens in the body of the text and define it as binary.
> 
Right,
(background: I did define a mapping for all OAuth parameters and 
re-mapped all that were Strings to binary. That does not necessarily 
mean the have a use case currently in ACE.)

in order to resolve this I will add a sentence in the description of the 
refresh token, saying that we define them to be binary here.


>>> ****** 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?
> 
> As long as the guidance is comment this is fine.  That is what I did
> for all of the COSE registries
> 

I'll copy liberally from your example then (and a bit from the CWT RFC). 
Hope you don't mind.


>>> 
>>> 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?
> 
> I thought about that, but it does not really cover the idea of having
> the nonce value there or the possibility of later adding things like
> - ok you should use this audience or this scope or some other similar
> thing.
> 

I see. I'll use the somewhat clunky but descriptive "ACE Authorization 
Server Request Creation Hints".

I've also taken the liberty of adding audience (req_aud) and scope as 
optional parameters in the AS Request Creation Hints message, in order 
to justify its name.



While resolving issues from the DTLS profile the authors have noticed
two elements that need to be added to the framework:

1.) A definition of "Authorization Information"
"The information an RS uses to determine wether a request is authorized, 
including the claims of applicable access tokens."

2.) Adding the "kid" parameter to the AS Request Creation Hints, so that 
a client can request a token with the same pop key when it has an 
existing security association, but the token has expired.
The procedure is currently defined in the DTLS profile, but it applies 
to any other profile as well and should therefore be in the framework.


/Ludwig

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