Denis
The objective of this document is to standardize the token the AS
shares with the RS. It is not to standardize how the client can read
the token. Just because the user is using the client, that does not
mean the user wants the client to see any claims about themselves.
Letting the client see the contents of the token may be a privacy
violation.
client != user
ᐧ
On Tue, Sep 8, 2020 at 9:10 AM Denis <[email protected]
<mailto:[email protected]>> wrote:
Hi Hannes,
Two comments between the lines.
Hi Victorio, Hi all,
I am doing my shepherd write-up for
draft-ietf-oauth-access-token-jwt-07. Reading through the draft I
have a few minor suggestions:
Section 2:
I would delete this sentence "JWT access tokens are regular JWTs
complying with the requirements described in this section."
Reason: You pretty much make the same statement on the previous
page (see terminology section).
Section 2.1
s/asymmetric algorithms/asymmetric cryptography
(same replacement in Section 4)
s/ This specification registers the "application/at+jwt" media
type,
which can be used to indicate that the content is an access
token./This specification registers the "application/at+jwt"
media type,
which can be used to indicate that the content is a JWT access
token.
Use capitalized "Section" when a section number is indicated,
such as in Section 2.2.
Section 2.2
s/""aud"/"aud"
2.2.1
s/ auth_time OPTIONAL - as defined in section 2 of
[OpenID.Core]./ auth_time OPTIONAL - as defined in Section 2 of
[OpenID.Core].
s/ acr, amr OPTIONAL - as defined in section 2 of
[OpenID.Core]./ acr, amr OPTIONAL - as defined in Section 2 of
[OpenID.Core].
s/Please see/See
s/For example:/For example,
Section 4
You write:
"Authorization servers SHOULD implement OAuth 2.0 Authorization
Server Metadata [RFC8414] ... "
Are you sure you mean "implement" and not "use"? The paragraph
gives me the impression that you talk about "ASs using RFC 8414"
s/Please see section Section 5 for further guidance on security
implications./Please see Section 5 for further guidance on
security implications.
This sentence sounds strange to me:
"
When invoked as described in OAuth 2.0 Bearer Token Usage
[RFC6750],
resource servers receiving a JWT access token MUST validate it
in the
following manner.
"
How about:
"
Resource servers receiving a JWT access token MUST validate it
in the
following manner.
"
Question: If you refer to RFC 6750 and then list the steps are
you just repeating the steps from RFC 6750 or are you augmenting
them?
You write:
"
If the JWT access token includes authorization claims as described in
the authorization claims section, the resource server SHOULD
use them
in combination with any other contextual information available to
determine whether the current call should be authorized or
rejected.
"
Include a reference to the authorization claims section
s/ For more
details on cross-JWT confusion please refer to 2.8 of
[RFC8725]./ For more
details on cross-JWT confusion please refer to Section 2.8 of
[RFC8725].
You write:
"
Authorization servers should not rely on the use of different keys
for signing OpenID Connect ID Tokens and JWT tokens as a method to
safeguard against the consequences of leaking specific keys.
"
The phrase "leaking keys" is probably not the best term to
describe what follows afterwards in the text.
You write:
"
The client MUST NOT inspect the content of
the access token
"
This RFC 2119 language is not really enforceable in terms of
interoperability. Maybe you could rephrase a bit. Something like
the following would work:
"
Authorization server and the resource server
might decide to change token format at any time (for example by
switching from this profile to opaque tokens). Hence, any
logic in the
client relying on the ability to read the access token content
would
break without recourse. The OAuth 2.0 framework assumes that
access tokens
are treated opaque by clients.
Administrators of authorization servers should also take into
account that
the content of an access token is visible to the client.
Whenever client
access to the access token content presents privacy issues for a
given scenario, the authorization server should take explicit
steps
to prevent it.
"
/In the general case, /the OAuth 2.0 framework assumes that access
tokens are treated as opaque by clients.
However, with this coming RFC, we are not in the general case:
since the client gets back an access token conformant to _this_
RFC, then it knows
exactly its detailed structure. The argument about "changing the
token format at any time" does not apply. In this case, the client
is quite sure
that it would be able to understand most of its content (at least
all the standard claims). The above text proposal would need to be
reconsidered.
Hiding (by encrypting it) the content of the access token to the
client is odd when an access token contains claims about a
human-user :
these claims are personal data and the human-user is usually
allowed to have access to his own personal data.
Encryption is nice in theory but complicated in practice, since a
key management system must put in place. Whenever possible, it
should be avoided.
BTW, some questions raised during the WGLC have not been answered:
How can a client request an access token compliant to this profile ?
Which parameter(s) allow it to ask an access token compliant to
this profile ? How can the AS know that it got a call for the
issuance of an access token
compliant to this profile ?
Another comment follows.
You wrote:
"
In scenarios in which JWT access tokens are accessible to the end
user, it should be evaluated whether the information can be
accessed
without privacy violations (for example, if an end user would
simply
access his or her own personal information) or if steps must
be taken
to enforce confidentiality. Possible measures include: encrypting
the access token, encrypting the sensitive claims, omitting the
sensitive claims or not using this profile, falling back on opaque
access tokens.
"
The first sentence is a repetition of the previous paragraph. I
would suggest to delete
the first sentence in this paragraph and to move the second
sentence to the previous paragraph.
You wrote:
"
This profile mandates the presence of the "sub" claim in every JWT
access token, making it possible for resource servers to rely
on that
information for performing tasks such as correlating incoming
requests with data stored locally for the authenticated principal.
Although the ability to correlate requests might be required by
design in many scenarios, there are scenarios where the
authorization
server might want to prevent correlation to preserve the desired
level of privacy. Authorization servers should choose how to
assign
"sub" values according to the level of privacy required by each
situation. For instance: if a solution requires preventing
tracking
principal activities across multiple resource servers, the
authorization server should ensure that JWT access tokens
meant for
different resource servers have distinct "sub" values tht
cannot be
correlated in the event of resource servers collusion.
Similarly: if
a solution requires preventing a resource server from
correlating the
principal's activity within the resource itself, the authorization
server should assign different "sub" values for every JWT access
token issued. In turn, the client should obtain a new JWT access
token for every call to the resource server, to ensure that the
resource server receives different "sub" and "jti" values at every
call, thus preventing correlation between distinct requests.
"
The above paragraph suggests that there are different levels of
privacy. What you are
talking about in the text is unlinkability and identification.
Ways to deal with such
privacy threats are described in Section 6 of RFC 6973.
Hence, I would suggest to slightly rephrase the paragraph to
something like:
"
This profile mandates the presence of the "sub" claim in every JWT
access token, making it possible for resource servers to rely
on that
information for correlating incoming
requests with data stored locally for the authenticated principal.
Although the ability to correlate requests might be required by
design in many scenarios, there are scenarios where the
authorization
server might want to prevent correlation. The "sub" claim
should be
populated by the authorization servers according to a privacy
impact
assessment. For instance, if a solution requires preventing
tracking
principal activities across multiple resource servers, the
authorization server should ensure that JWT access tokens
meant for
different resource servers have distinct "sub" values that
cannot be
correlated in the event of resource servers collusion.
While the idea is really nice, the use of the "sub" claim in this
context is not compatible with the definition of the "sub" claim
as defined in RFC 7519:
4.1.2. "sub" (Subject) Claim
The "sub" (subject) claim identifies the principal that is
the
subject of the JWT. The claims in a JWT are normally
statements
about the subject. *The subject value MUST either be
scoped to be**
** locally unique in the context of the issuer or be
globally unique.*
The processing of this claim is generally application
specific. The
"sub" value is a case-sensitive string containing a
StringOrURI
value. Use of this claim is OPTIONAL.
There are two options and two options only:
"locally unique in the context of the issuer" means that it is
the same for all RSs.
"globally unique" means that it is the same not only for all
the RSs but also for servers that have nothing to do with
OAuth (e.g. an email address).
Similarly, if
a solution requires preventing a resource server from
correlating the
principal's activity within the resource itself, the authorization
server should assign different "sub" values for every JWT access
token issued. In turn, the client should obtain a new JWT access
token for every call to the resource server, to ensure that the
resource server receives different "sub" and "jti" values at every
call, thus preventing correlation between distinct requests.
The proposed text describes two different cases where the sub
claim is either unique for an AS/RS pair orunique for each access
token.
These two cases are not included in the definition found in RFC 7519.
In the general case, an identifier can be:
1. locally unique in the context of the issuer (i.e. the same for
all RSs),
2. globally unique (i.e. the same not only for all the RSs but
also for servers that have nothing to do with OAuth),
3. unique for an AS/RS pair, or
4. unique for each access token.
I see different ways to solve this problem:
1° Stick to the definition of RFC 7519 and (unfortunately)
remove these possibilities.
2° Define two new claims which would support the two cases
where the sub claim would be either unique for an AS/RS pair
orunique for one access token.
3° Define four new claims which would support the four above
cases.
Denis
"
Section 7.2
s/ Section Section 2.2.3.1 of this specification refers to the
attributes "roles", "groups", "entitlements" defined in
[RFC7643] to
express authorization information in JWT access tokens.
/ Section 2.2.3.1 of this specification refers to the
attributes "roles", "groups", "entitlements" defined in
[RFC7643] to
express authorization information in JWT access tokens.
References
RFC 7519 has to be a normative reference:
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>
<https://www.rfc-editor.org/info/rfc7519>.
RFC 7644 is an unused reference:
[RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E.,
and C. Mortimore, "System for Cross-domain Identity
Management: Protocol", RFC 7644, DOI 10.17487/RFC7644,
September 2015, <https://www.rfc-editor.org/info/rfc7644>
<https://www.rfc-editor.org/info/rfc7644>.
The same is true for RFC 3986:
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>
<https://www.rfc-editor.org/info/rfc3986>.
Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments
are confidential and may also be privileged. If you are not the
intended recipient, please notify the sender immediately and do
not disclose the contents to any other person, use it for any
purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
