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 +46(0)70-349 92 51
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
