Re: [Ace] WGLC for draft-ietf-ace-authz

[Jim Schaad <[e-mail]>]

* Section 3.1 - Refresh Token - I don't think that refresh tokens are going
to be strings because binary is more efficient.

* Section 3.2 - we need to reference TLS 1.3 even if DTLS 1.3 is not yet
available.

* Description for Figure 6 -  Should the example somehow indicate in the
message that it is going to be an application/ace+cbor content.   Also, I
don't know that this is a good example in some ways because this is not a
currently documented profile anywhere.

* Section 5.6.3 - Should the content type for an error response be
application/ace+cbor ?

* Section 5.7.1 - Is the content format for a request application/ace+cbor?
I assume it is but that is not documented in this section.

Section 5.8 - bytes arrays or byte strings?  I think CBOR uses the latter

* Section 5.8.1 - What is the purpose of creating an identifier for a token?
Is this supposed to be used rather than the one from the AS for something
like shared secret TLS?  Note that this is an unprotected value.

* Section 5.8.1 - Given the change in the OSCORE profile, you might want to
make this an application/ace+cbor structure as well.

* Section 5.8.1 - If the token is "not valid" is the RS required (i.e. MUST)
to try introspection before returning a response if the RS does
introspection?  The text currently says MAY.  If this is really MAY then the
text should say that the token is always successfully accepted by the RS.

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

* Section 5.8.3 - third point - I think that the correct text would be "The
method does not provide timely expiration, but it makes sure that older
tokens will cease to be valid after newer issued tokens are registered with
the RS."  My problem is that just issuing tokens is not enough as they may
be going to a different RS for use.  This may also need to have some type of
rate limit to issued tokens or making the sequence number be on an
RS/audience basis.

* Section 6. - The recommendation not to use a shared secret for an audience
which is hosted by multiple servers is interesting.  This does require that
a multiple recipient COSE structure be used and it may be worth calling that
out.  Also the size of the CWT is going to grow for that.  You are also now
losing the low-level authentication and thus a signature wrapping is now
also needed.

* Section 6 - "Developers MUST" para - May want to add that this can also be
mitigated to some extent by making sure that keys roll over more frequently.

* Section 6 - I am not sure that I agree with the SHOULD NOT in the last
paragraph.  Think multicast.

* Section 6.4 - This also applies to sending back some type of identifier
from the RS->C when a token is registered.

* Section 8.6.1 - Is pop still this document or is it Mike's document?

* Section 8.9 - The description of reference is wrong.

* Section 8.12 - some of these should move to the OAuth parameters document?

* Section 8.13 - ditto

* Appendix A -  para "CBOR, COSE, CWT"  - Is it really a requirement to use
CBOR or is that a recommended?  I thought this was part of what Hannes was
looking at.

* Appendix A - para Client Credentials Grant  s/can the/can then/

* Registries -  I am wondering if we should think about re-writing a couple
of the registries.  As things stand it appears that the application/ace+cbor
content type is being used in 5 or 6 places.  It might make more sense to
have a registry for all of the CBOR abbreviations that are being used in a
single table and have multiple columns for each of the different places were
the content format is being used.  This would make it easier to keep
everything constant and can make re-use of integer values easier to see.  

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

* I am not sure where this issue should be raised so I am putting it here.
Both of the profiles have as their last security consideration a statement
that the use of multiple access tokens is a bad idea.  Both of them also
devote a large section of text to how to deal with multiple access tokens as
does this document.  More methods of having multiple access tokens seem to
be coming down the path from the OAuth group.  This appears to be a distinct
contradiction within the set of documents that should be resolved.  

Jim