Hi Vittorio,
Thank you for your fast response.
You wrote:
"/It doesn’t look very likely that an RS would simply accept tokens
from an AS without some out of band negotiatio/n, "
and also:
"/As far the client is concerned, the RS and the AS might switch
their agreement/"
With such sentences, it seems that you mandate a direct negotiation
between the AS and the RS which, by implication,
means that the AS and the RS must know each other, which is exactly what
I want to avoid. Such some out of band negotiation
can simply be done by publishing which AT formats the AS is able to
generate and which AT formats the RS is able to accept.
An AS can publish metadata relevant to the JWT access tokens it issues
and a RS can do the same.
In this way, the client could consult both published lists and choose
which common format, if any, would be appropriate.
This means that the client should be able in its AT request to specify
the format of the AT, thus avoiding any direct some
out of band negotiation between the AS and the RS.
You continue saying:
" /nor it seems very likely that an AS would issue tokens for
resources it doesn’t know/".
This is where we have a major difference in our points of views. The
number of AS is likely to be several order of magnitudes higher
compared to the number of RS. Every time a RS is being established, it
should not have to make itself known to any AS.
This is why I wrote:
/"a key point is that an AS and a RS DO NOT necessarily need to know
each other. *The RS only needs to trust the AS*/*.*/(full stop)"/
You are assuming that an AS and a RS necessarily need to know each other.
You wrote:
"/The scenario in which a token issuer isn’t aware of where the
client will spend the corresponding token is important,
but it is more the province of SSI than mainstream OAuth2 usage today"./
Today, as soon as an AT is targeted, the AS will be aware where the
client is likely to spend the AT. The reality is that the scenario
in which a token issuer will not be aware of where the client will spend
the corresponding token is today completely out of the scope
of OAuth2 usages (unfortunately, it is not a matter of mainstream or not).
For that reason, if the spec. continues to prevent to implement "Privacy
by design" architectures and worse, mandates "Spy by design"
architectures, this should be clearly advertised in the Privacy
Considerations section.
You recommend to specify the split AT structure I suggest in its own
spec rather than in an interop profile for the general AT case.
The current title of the document is: "JSON Web Token (JWT) Profile for
OAuth 2.0 Access Tokens". The content of the document
is much more than what the title implies since the introduction states :
"Besides defining a common set of mandatory and optional claims, the
profile provides clear indications on how determine the content of
the issued JWT access token, how an authorization server can publish
metadata relevant to the JWT access tokens it issues, and how
a resource server should validate incoming JWT access tokens".
The document specifies a protocol with severe limitations in the
authorization requests parameters and with severe limitations for the
validation of AT.
If the spec. stays like that, it should rather be called:
* "JSON Web Token (JWT) *Basic Protocol* for OAuth 2.0 Access Tokens" or
* "JSON Web Token (JWT) *Basic Protocol and Profile* for OAuth 2.0
Access Tokens".
In the future, a true Profile for OAuth 2.0 Access Tokens could then be
written.
The case where a client would be able to inspect the content of a
generated AT, indeed comes into contradiction with the case where the AS
would encrypt
its content for the intended recipient and you advocate that it is
another reason "for which the AS in the general case needs to know the
intended recipient".
It is not the general case, but a specific case, which is more difficult
to deploy than the simplest case where RS only need to know the AS that
they trust.
It is a trade off /for the client/ to be able to inspect itself the AT
of to make sure that only the RS will be able to inspect the AT.
I wrote:
"This means that an identifier of the profile of the AT should be
able to be included into the AT. This allows for future extensions."
You replied:
"Can you expand on the exact scenario you are thinking of that calls
for a version?"
Identifier formats for AT should be able to be included into :
* the metadata published by the AS,
* the metadata published by the RS, and
* the AT itself.
The sketch of the scenario would be as follows.
The client consults both the metadata published by the AS and the
metadata published by the RS and tries to find matches between token
formats.
If there are several matches, it will choose,if possible, a match where
it can access and understand the content of the AT. It will then inform
the AS
of its choice by adding the identifier of the profile of the AT in the
AT request. The AS will also include the identifier of the profile of
the AT in the AT
so that the RS, when it receives the AT, can unambiguously decode the AT.
Finally, I will copy the end of your email.
> Allowing a client to only specify a scope and a resource is very
restrictive.
Specifying scope or using resource indicators are all the mechanisms
I am aware of that OAuth2 offers for specifying what an access token
should be for - at least at the time in which the spec was incepted.
(...) .
What other interoperable mechanisms would you offer in addition to
the ones listed here?
The client should be able to specify in its AT request additional
attributes whose semantic is well described by the attributes description
found in section 5.1 of [OpenID.Core] or the attributes description
found in [RFC7662] or other identity related specifications.
*Another new and last comment*: it is quite odd that there is no formal
description of an AT profile anywhere in the current document.
A syntax description would greatly enhance interoperability.
Denis
Hi Denis,
Thank you for your feedback!
Inline
/> Privacy has not really been a concern in the WG since originally
the AT and the RS were co-located./
Colocation of AS and RS was a frequent occurrence, but by no mean
mandatory… AFAIK one of the drivers for the changes between OAuth1 and
OAuth2 was providing the ability of supporting topologies where AS and
RS are distinct right out of the box.
The scenario where AS and RS are distinct was always possible in
Outh2, and and not by accident. The JWT AT just happens to be
particularly handy in empowering the RS to validate incoming tokens
without having to phone home to the AS every time, hence it gives the
opportunity to discuss implications of that scenario more in depth,
but doesn’t really introduce anything that wasn’t possible before.
Even the possibility of a token format passing info by value isn’t
forbidden, default OAuth2 ATs are not mandatorily opaque- they just
happen not to have a well defined format.
*/>In such cases/*/, it is important to be able to make sure that an
authorization server will NOT be able to know where the authorizations
tokens that it issues will be used. Using another wording, an AS SHALL
NOT be able to know where an AT requested by a given client will be used:
*Authorization servers SHALL not have the capability to act as "Big
Brother"* and thus SHALL not be able to know which resources are going
to be accessed by clients./
The scenario in which a token issuer isn’t aware of where the client
will spend the corresponding token is important, but it is more the
province of SSI than mainstream OAuth2 usage today.
Mainstream OAuth2 in current use, regardless of the AT format,
typically do know for whom the token is being issued: a great deal of
logic is predicated on that knowledge. Did the user consent for this
client to access this particular resource? Does access to this
resource warrant presenting a stronger authentication prompt? Are
there other authorization considerations that influences whether the
requested token should be issued? Those are considerations an AS need
to be able to perform in the general case, regardless of the AT
format. That doesn’t mean they MUST be done in every case, but making
them impossible would deny a lot of very important scenarios for which
JWT ATs (and ATs in general) are used for today.
The split structure you suggest is interesting, but I would recommend
is enshrined in its own spec (maybe in the SSI orbit) rather than in
an interop profile for the general AT case.
/>On the contrary, a client SHALL be able to inspect the content of
the access token to make sure that the AS has not included in the AT
some private information
that should not be present, before forwarding the AT to the RS. It is
possible for an AS to change the format of the AT, but the RS will not
necessarily be in synch
with the RS.///
I can see the value in doing what we can to prevent abuses, but I find
this requirement problematic. The access token is an artifact meant to
enable the client to access a resource. Its format remains a private
matter between the RS and the AS, which retains the freedom to change
it as they see fit without worrying about client code that takes a
dependency on characteristics of the AT that might very well be
transient. As far the client is concerned, the RS and the AS might
switch their agreement from JWT AT to opaque tokens to be validated
via introspection at any time, which would break any client side logic
inspecting the AT and expecting it to be a JWT. The client has no
control whatsoever on the content that is transmitted via opaque
token, hence privacy-wise the fact that the content of the JWT is
visible is more of a concern about such content being accessible on
the client. One additional point: even if clients would be able to
safely peek inside an AT without risking breaking their code, there’s
no guarantee that the client would understand the semantic of the
claims in the AT, as those are meant for consumption by the RS which
can assign any semantic to them; nor the client can reliably trust the
content of the claims, given that the AS could and sometimes will
encrypt their content for the intended recipient (another reason for
which the AS in the general case needs to know the intended recipient).
/>. It is possible for an AS to change the format of the AT, but the
RS will not necessarily be in synch with the RS. /
I don’t understand this sentence. Is the last RS meant to be AS?
Assuming that’s the case: It doesn’t look very likely that an RS would
simply accept tokens from an AS without some out of band negotiation,
nor it seems very likely that an AS would issue tokens for resources
it doesn’t know- see above. Such scenarios might exist, but they don’t
seem to model common business solutions or the typical deployment,
where an API will be protected by middleware/gateway with precise
assumptions on how to validate incoming tokens. There might be changes
that are inconsequential (order of claims, additional claims) but
anything more substantive would likely simply break the solution.
/> This means that an identifier of the profile of the AT should be
able to be included into the AT. This allows for future extensions.///
Can you expand on the exact scenario you are thinking of that calls
for a version? If it’s a matter of extensions, those should always be
possible – it’s more breaking changes that require versioning, but I
don’t recall precedents in similar specs.
If this is aimed at mitigating the “AS changes format without telling
RS”, I don’t think that would work – besides of being unnecessary per
the above considerations, this wouldn’t protect the RS from changes
well within the current spec (which allows adding arbitrary claims as
long as it’s done according to JWT rules), from changes within the
claim content (eg private string formats) and from complete departures
from the use of JWT for ATs.
/>//Allowing a client to only specify a scope and a resource is very
restrictive./
Specifying scope or using resource indicators are all the mechanisms I
am aware of that OAuth2 offers for specifying what an access token
should be for- at least at the time in which the spec was incepted. In
fact, resource indicators was not even RFC and in market vendors used
proprietary functional equivalents. What other interoperable
mechanisms would you offer in addition to the ones listed here?
*From: *OAuth <oauth-boun...@ietf.org> on behalf of Denis
<denis.i...@free.fr>
*Date: *Thursday, April 9, 2020 at 09:26
*To: *oauth <oauth@ietf.org>
*Subject: *Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for
OAuth 2.0 Access Tokens"
I have three concerns, two of them being related to privacy.
1) Privacy has not really been a concern in the WG since originally
the AT and the RS were co-located. However, this draft now recognizes
that there may exist cases where "the authorization server and
resource server are not co-located, are not ran by the same entity,
or are otherwise separated by some boundary".
*In such cases*, it is important to be able to make sure that an
authorization server will NOT be able to know where the authorizations
tokens that it issues will be used. Using another wording, an AS SHALL
NOT be able to know where an AT requested by a given client will be used:
*Authorization servers SHALL not have the capability to act as "Big
Brother"* and thus SHALL not be able to know which resources are going
to be accessed by clients.
This means that, in such cases, an authorization server SHALL not be
able to know for which resource server an AT has been targeted.
It is a fact that most solutions currently deployed support a built-in
*"Spy by design"* architecture instead of a *"Privacy by design"*
architecture.
However, for security reasons an AT still needs to be targeted.
The problem to be solved is the following:
* for security reasons, the AT must be targeted.
* for privacy reasons, the AS must be kept ignorant of the name of
the target.
One way to solve the problem is to consider that the AT is composed of
a sequence of two structures: a signed structure and an unsigned
structure.
The signed structure contains a "salted aud claim".
The unsigned structure contains a "aud salt claim".
In practice, the "salted aud claim" will be composed of both a one way
hash function algorithm identifier and a hash value.
Before requesting an AT to an AS, the client chooses a resource server
and select a resource indicator value corresponding to the identifier
the resource server.
It then chooses a random value which it uses as a "aud salt claim" and
then computes a hash value by using a one-way hash function which
combines
one of the resource indicators of the RS with the "aud salt claim".
Both the one way hash function algorithm identifier and the computed
hash value
are then included into the "salted aud claim".
The AT request then contains a "salted aud claim" instead of an"aud
claim". The AT blindly copies this value into the AT which is then
identified as
a "salted aud claim" instead of an "aud claim".
When the AT is received by the client, it adds to the AT the unsigned
part to the AT which contains the "aud salt claim" and sends both the
signed
and the unsigned part of the AT to the RS.
When the RS receives the AT, using the one way hash function algorithm
identifier contained in the "salted aud claim", it combines each of
its resource indicators
with the "aud salt claim" contained in the unsigned part of the AT and
verifies whether it matches with the hash value contained in the
"salted aud claim".
If none of these resource indicators is providing a match, then the RS
SHALL rejected the AT.
The implication is to allow an AT to contain both a signed part and an
unsigned part.
In addition, the "aud claim" should be multi-valued where, as a
consequence, both the "salted aud claim" with the "aud salt claim"
would also be multi-valued.
2) Within clause 6, "Privacy Considerations", the text states:
As JWT access tokens carry information by value, it now becomes
possible for requestors and receivers to directly peek inside the
token claims collection. The client MUST NOT inspect the content of
the access token: the authorization server and the resource server
might decide to change token format at any time (...).
On the contrary, a client SHALL be able to inspect the content of the
access token to make sure that the AS has not included in the AT some
private information
that should not be present, before forwarding the AT to the RS. It is
possible for an AS to change the format of the AT, but the RS will not
necessarily be in synch
with the RS.
Since there are now cases where "the authorization server and resource
server are not co-located, are not ran by the same entity, or are
otherwise separated
by some boundary", a key point is that an AS and a RS DO NOT
necessarily need to know each other. The RS only needs to trust the
AS. (full stop)
This means that an identifier of the profile of the AT should be able
to be included into the AT. This allows for future extensions.
In any case, the "MUST NOT" in the quoted sentence should be removed
or changed or the whole sentence should be removed..
3) Within clause 2.2.2 (second paragraph):
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.
Allowing a client to only specify a scope and a resource is very
restrictive.
What would be the title of an RFC that would allow the client to
request the presence of specific claims in JWT access ?
If such a restriction is kept, would the current title of this RFC
still be inappropriate
"JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" ?
Denis
DP Security Consulting
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
