Hi Vittorio!
Thanks for the answers. I'm ok with the motivation for using
"application/at+jwt", thanks for clarifying, and thanks for addressing 2.
Re 1. IMO it would clarify the intention of the SHOULD to add what you wrote in
response to my comment into the draft itself, but I'll leave it up to you.
Francesca
On 14/04/2021, 09:19, "Vittorio Bertocci" <vittorio.berto...@auth0.com> wrote:
Hi Francesca,
Thanks for your review and thoughtful comments!
Comments below.
> 1. -----
> [...]
While it is reasonable to expect that a RS receiving an unencrypted token
after requesting it to be encrypted will reject it, there are a number of cases
where the RS might elect to do otherwise. For example, the solution might be
already working in production: the encryption requirement might be an
improvement that is still propagating thru the system, and there might still be
access tokens cached in clients that the RS might still be willing to accept to
guarantee business continuity. "SHOULD" gives a strong signal to implementers
of what the desired behavior is, but leaves them some freedom to accommodate
situations like the aforementioned one.
> 2. ---
> [...]
Fair enough. I added the following text at the beginning of 2.1. Thanks for
catching this.
JWT access tokens MUST be signed. Although JWT access tokens can use
any signing algorithm[..]
This change will appear in the next revision, which I will post soon.
> 3. -----
> [...]
Formally, I agree that JOSE would also work. The choice of media type
derives from https://tools.ietf.org/html/rfc7519#section-10.3.1. There is no
functional difference between JWS and JWE in the intent a client has when
calling an RS, here there's not much to be gained in using different MIME types
for those cases. Furthermore, whereas developers are familiar with the term
"JWT", both from direct use and thanks to the popularity of OpenID Connect
(which does use application/jwt), terms like JWS, JWE or JOSE wouldn't be as
promptly understood as JWT. Throughout the discussions in the last couple of
years, the consensus on the use of at+jwt was solid- my hope is that will make
intuitive sense for implementers, too.
On 4/4/21, 11:01, "Francesca Palombini via Datatracker" <nore...@ietf.org>
wrote:
Francesca Palombini has entered the following ballot position for
draft-ietf-oauth-access-token-jwt-12: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Thank you for the work on this document. Please find some comments and
clarifying questions below.
Francesca
1. -----
registration. If encryption was negotiated with the authorization
server at registration time and the incoming JWT access token is
not encrypted, the resource server SHOULD reject it.
FP: Why is this just SHOULD and not MUST? In which case does it make
sense to
accept a non-encrypted token when encryption was negotiated?
2. -----
Section 2.1:
Section 4). JWT access tokens MUST NOT use "none" as the signing
algorithm. See Section 4 for more details.
Section 4:
For the purpose of facilitating validation data retrieval, it is here
RECOMMENDED that authorization servers sign JWT access tokens with an
asymmetric algorithm.
...
o The resource server MUST validate the signature of all incoming
JWT access tokens according to [RFC7515] using the algorithm
specified in the JWT alg Header Parameter. The resource server
FP: It might be obvious, but I think it would be useful to have an
explicit
sentence stating that JWT MUST be signed. The quoted text from Section
2.1 seem
to imply it. Section 4 only RECOMMENDS that the JWT is signed with and
asymmetric algorithm. Later on, Section 4 implies that all JWT are
signed. On
the other hand I note that encryption can be negotiated (and is
optional) from
the followig point; in that case it is not clear that the token is
still signed
(so the nested JWT would be a JWE nested in a JWS), or only JWE is
used. What I
am looking for is simple clarifications to be added for example in the
introduction.
o If the JWT access token is encrypted, decrypt it using the keys
and algorithms that the resource server specified during
registration. If encryption was negotiated with the authorization
3. -----
On the same note, and depending on the previous answer, why is the
media type
registered and used "application/at+jwt" and not something like
"application/at+jws"/"application/at+jwe" or rather
"application/at+jose" to be
compliant with
https://protect2.fireeye.com/v1/url?k=cf968f69-900db66b-cf96cff2-869a14f4b08c-d9afc9515caac1c4&q=1&e=e0795065-865a-4950-87a5-ac1b2b1d8e58&u=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7515.html%23section-9.2.1
? I
think that the structure transported is in fact a JWS or a JWE, rather
than the
JWT, and if that's the case that should be made clear in the text (one
example
where this could be clarified is in the following sentence)
Resource servers receiving a JWT access token MUST validate it in the
following manner.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
