On 30/01/2019 19:23, Jim Schaad wrote:
-----Original Message----- From: Ludwig Seitz <ludwig.se...@ri.se>
Sent: Wednesday, January 30, 2019 12:38 AM To: Jim Schaad
<i...@augustcellars.com>; draft-ietf-ace-oauth- au...@ietf.org Cc:
ace@ietf.org 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 +46(0)70-349 92 51
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
