Hi Benjamin,
Responses are between the lines.
On Fri, May 22, 2020 at 11:37:28AM +0200, Denis wrote:
Hi Benjamin,
On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote:
Since then, I questioned myself how a client would be able to
request an access token that would be *strictly compliant with this
Profile*.
I don't understand why this is an interesting question to ask. The
access token and interpretation thereof is (AIUI) generally seen as
an internal matter between AS and RS, with the client having no need
to care about the specifics.
This document is*_a_* Profile for OAuth 2.0 Access Tokens. It is not
_*the*_ Profile for *_all_ *OAuth 2.0 Access Tokens.
Sure. But (in my understanding), in common usage, the contents and
interpretation of the access token is set by common agreement between
AS and RS, with the client serving only as a "dumb" channel for
transporting the token. That is, we're providing a token format that
an RS and AS can agree to use, most likely for all tokens issued by
the AS for that RS. I don't know of any existing mechanisms, or desire
for such mechanisms by deployments, for using a different token format
for different tokens issued by a given AS for a given RS.
Since this document is *_a_* Profile for OAuth 2.0 Access Tokens, it
means that potentially other Profiles could be defined in the future.
In the request, there is no parameter for a client to indicate that it
wants a JWT conformant to _this_ profile and no parameter either
in the response to indicate to the client that it got a JWT that is
conformant to _this_ profile.
The processing mandated in the document of a request made by a client to
an AS only applies for a request conformant to this profile
which may or may not include a scope parameter and which may or may not
include a "resource" parameter (and, if it does not, shall
include an "aud" claim). Currently, it is not possible to make a
difference between a JWT request or response conformant to this profile
and other JWT requests or responses.
Attempting to have the client provide input that would affect such a
mechanism seems like complexity with no market demand; a "solution in
search of a problem" as it were. Is there some pent-up demand among
OAuth deployments that I'm not aware of? I freely admit to not being
very on top of the broad spectrum of what's deployed...
1) A client may wish to obtain an Access Token that corresponds to
this Profile because, for example, this document mandates the "sub"
claim to be present". Hence, the content of the Access Token is not
totally "/an internal matter between AS and RS/". However, I have not
understood how a client could request an Access Token that
corresponds to *_this_***Profile, since there is no mandatory
parameter in the request (both the "scope" parameter and the
"resource" parameter are optional). In the future, we could define
_*another*_**Profile. Hence, there is the same question: How could a
client request an Access Token that corresponds to *_that
other_***Profile ? 2) When getting a JWT, how can the client make
sure that the access token it got is compliant with this Profile ?
RFC 8725 states in section 3.11 : 3.11. Use Explicit Typing
Sometimes, one kind of JWT can be confused for another. If a
particular kind of JWT is subject to such confusion, that JWT can
include an explicit JWT type value, and the validation rules can
specify checking the type (...). Explicit JWT typing is accomplished
by using the "typ" Header Parameter. Wouldn't be wise to include an
explicit JWT type value for JWTs conformant to this Profile ?
In the model where the client is a "dumb" communications channel, this
question does not seem interesting. But the related question of "how
can the RS make sure that the access token it got was generated
according to this profile?" does seem interesting, and seems like it
would benefit from the same proposed solution.
An explicit JWT type value added both in the JWT request and in the JWT
response would solve this problem.
This relates to an email posted by Dominick Baier under the topic
"JAR: JWT typ" on May 19 : This has been brought up before - but no
response. Either I can’t find it - or it is missing. But is the
setting the JWT typ explicitly mentioned somewhere?
It is fairly likely that I will remember to ask about explicit "typ"
usage if I'm still on the IESG when this document gets there: I think
I've been making a habit of doing so.
Once again, an explicit "typ" sould be considered for both the JWT
request and the JWT response. This implies that the client "MUST" be
able to inspect the content of the access token.
Denis
Thanks, Ben
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
