Hi Vittorio,
draft-ietf-oauth-access-token-jwt states in section 2.2.2:
This profile does not introduce any mechanism for a client to directly
request the presence of specific claims in JWT access tokens,
as the authorization server can determine what additional claims
are required by a particular resource server by taking in consideration
the client_id of the client, the scope and the resource
parameters included in the request.
RFC 6750 states in section 3 :
(...)
Use of the "scope" attribute is OPTIONAL. The "scope" value is
intended for programmatic use and is not meant to be displayed to end-users.
This has the following consequence: the end-user is usually not able to
know which attributes correspond to a scope (or to a missing scope).
The only way to know is to look at the content of the token and the
reason for doing this may be related a privacy consideration.
RFC 6749 states in section 1.4: "The string [access token] *is usually
opaque* to the client".
However, this sentence does not mean : "The client *MUST NOT* inspect
the content of the access token".
RFC 6749 does not contain a MUST, SHALL or SHOULD in the above quoted
sentence. In such a situation,
we should not be "more royalist than the King"
Benjamin Kaduk wrote:
"*I do in fact agree that token inspection by a client can be
useful in at least some situations*".
This being stated, hereafter is a full text proposal replacement for the
first paragraph (12 lines)
of the Privacy Considerations section (section 6):
As indicated in RFC 6750, the "scope" value is intended for
programmatic use and is not meant to be displayed to end-users.
This means that, even when the client uses the scope parameter, the
end-user will usually have no knowledge of the attributes
which correspond to the scope (or to a missing scope parameter).
RFC 6749 mentions that the string [access token] is usually opaque
to the client. Hence, the client will not necessarily be able
to inspect the content of the access token. As an example, an
authorization server and a resource server might decide to change
the access token format at any time.
There are however cases, where the access token content presents
privacy issues for a given scenario. In such cases,
the end-user would like to know which attributes have been placed in
a token before forwarding it to a resource server.
If these attributes do not correspond to the expectations of the
end-user or if the format of the access token is not understandable
by the client, then the client SHOULD NOT forward the access token
to the resource server.
Denis
It’s not really an interop issue either, given that following or not
following this requirement doesn’t alter the shape of messages or
tokens. It’s more of an architectural requirement, which preserves the
relationships between the OAuth2 roles involved and prevents the
confusion that might arise by the availability of data that
characterizes this particular scenario, but that doesn’t change the
more general premises of the protocol. In terms of finding common
ground, I am not sure if visions as diametrically opposed as pitting a
MUST against a MUST NOT have much of an achievable common ground,
especially given that the MUST NOT stance already passed consensus in
the past year, and in more than one month of very public debate during
last calls, the MUST side had mostly one backer and more than one
opposed.
*From: *Jared Jennings <jaredljenni...@gmail.com>
*Date: *Monday, May 11, 2020 at 20:14
*To: *Vittorio Bertocci <vittorio.berto...@auth0.com>
*Cc: *Denis <denis.i...@free.fr>, Benjamin Kaduk <ka...@mit.edu>,
"oauth@ietf.org" <oauth@ietf.org>
*Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
for OAuth 2.0 Access Tokens"
Hi Vittorio,
Yeah, this does make a bit of sense. So, the goal is to guide
implementors from making bad choices, not from a security perspective.
Meaning, it's not a security risk that a client does inspect or
analyze the token. Instead, it's is an interop issue and thus we are
guiding implementors to never assume or expect the token format to be
consistent or of a expected format, for various reasons. I kinda know
the answer to this question, but I am kinda asking this way to help
restate the intent of the "topic" and maybe help guide to a wording
that works for everyone.
For example, as a consultant, it can be very helpful to know how to
decompile or inspect an "Object", but at the same time knowing that
such a method or practice should never be used in production.
Jared
On May 11, 2020, at 19:24, Vittorio Bertocci
<vittorio.berto...@auth0.com <mailto:vittorio.berto...@auth0.com>>
wrote:
Real world scenarios are full of situations where additional
assumptions can lower dangers that must be taken in consideration
in the general case, which might make less of a risk going against
the spec/in those particular circumstances/, but their existence
doesn’t warrant relaxing guidance for the general case. A concrete
example: I worked on scenarios where resource servers wanted to
guarantee some degree of business continuity in case of AS outage,
which boiled down to RS’ willingness to accept ATs past their
declared expiration time, on the condition that the AS outage
condition was detectable and the staleness of the AT didn’t cross
a tolerance threshold. The business scenario made sense, and the
implementer was within their right in deciding that disregarding
exp in those circumstances was acceptable. Nonetheless, I would
not argue that given the existence of that scenario, rfc7519
should turn its MUST NOT into a SHOULD NOT.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
