Additional comments below:
*From:* Denis <denis.i...@free.fr>
*Sent:* Thursday, September 10, 2020 11:41 AM
*To:* Hannes Tschofenig <hannes.tschofe...@arm.com>
*Cc:* Dick Hardt <dick.ha...@gmail.com>; oauth@ietf.org
*Subject:* Re: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-07
Hi Hannes,
Thank you for responses. See below.
Hi Denis,
Hi Dick and Hannes,
1) While reading RFC 7519, no reader may be able to figure out
that there are more than two flavours of the "sub" claim.
This draft is introducing two new other favours of the semantics
of the "sub" claim which are not present in RFC 7519.
When an element has been defined, its semantics cannot be
changed ... unless making an Errata to RFC 7519
which would be a clean way to proceed.
[Hannes] What do you mean by “flavours” of the subject claim?
[Denis] RFC 7519 states: The subject value MUST *either *be scoped to
be locally unique in the context of the issuer *or * be globally unique.
This makes two flavours: *either *locally unique in the context of the
issuer *or *globally unique.
When reading the current text, in addition to these two flavours, two
additional flavours (3) and (4) are discovered
which makes a total of four flavours:
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, and
4. unique for every access token.
2) The argument about "changing the token format at any time" does
not apply in the context of this future RFC.
This sentence should be either removed or modified This means
that the following sentence which is a derivative
of this sentence should also be either removed or modified:
Hence, any logic in the client relying on the ability to read
the access token content would break without recourse.
[Hannes] The OAuth 2.0 architecture allows the authorization
server and the resource server to agree on whatever token
format they want.
They can pass the information by value or by reference (which
may then require token introspection or an equivalent mechanism).
This document does not change anything concern this.
Imagine a third party implementing an OAuth 2.0 Client. If
they make assumptions about the ability to parse the content
of the token, we create a brittle system.
For this reason, the sentence "changing the token format at
any time" is correct.
I hope this makes sense.
[Denis] I do not dispute the sentence you proposed "The OAuth 2.0
framework assumes that access tokens are treated opaque by clients"
which replaces the previous sentence which was: "The client MUST NOT
inspect the content of the access token".
The two sentences prior to it are:
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.
Once having read your last three responses, I would propose the
following small change in the second sentence:
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 /at an instant of time might /break /later
on/ without recourse.
You may have noticed that I proposed to change the RFC 2119
language in the text. I changed my original proposal to make
it more clear (see red text).
"
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 software relying on the ability to read the access
token content may
break since 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.
"
3) The following questions have still not been answered:
Some questions raised during the WGLC have not been answered:
How can a client request an access token compliant to this
profile ?
[Hannes] The client cannot request the authorization server to
use a specific token format. Since the client is not going to
look at the access token content why would it even care.
[Denis] While reading all of your three last responses, I now
understand the point.
Which parameter(s) allow it to ask an access token compliant
to this profile ?
[Hannes] There no parameters defined so that the client can
ask for an access token format that is compliant to this profile.
OK.
How can the AS know that it got a call for the issuance of an
access token compliant to this profile ?
[Hannes] The AS only gets a request for an access token and
the AS needs to decide what format to use, like it did in the
past. Nothing changed.
Your response does help to understand. Section 3 is stating:
An authorization server /can /issue a JWT access token in response
to any authorization grant defined by [RFC6749] and
subsequent extensions meant to result in an access token.
I believe, it would be worthwhile to add a sentence, just after this
sentence, with the following text:
When an authorization server decides to issue a JWT access token
compliant to this profile, then the following requirements apply.
(...)
[Hannes] That’s fine for me because this is what the intended effect
of the spec is.
Ciao
Hannes
Denis
Ciao
Hannes
Denis
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 <denis.i...@free.fr
<mailto:denis.i...@free.fr>> 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 or unique 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 or unique 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
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
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.
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.
