Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Benjamin Kaduk <kaduk@mit.edu> Sun, 12 April 2020 02:15 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8281A3A1BF5 for <oauth@ietfa.amsl.com>; Sat, 11 Apr 2020 19:15:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPVeEbQuHsCl for <oauth@ietfa.amsl.com>; Sat, 11 Apr 2020 19:14:57 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C93623A1BF4 for <oauth@ietf.org>; Sat, 11 Apr 2020 19:14:56 -0700 (PDT)
Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03C2EnnY023142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 11 Apr 2020 22:14:51 -0400
Date: Sat, 11 Apr 2020 19:14:49 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Denis <denis.ietf@free.fr>
Cc: Vittorio Bertocci <vittorio.bertocci@auth0.com>, oauth <oauth@ietf.org>
Message-ID: <20200412021449.GM88064@mit.edu>
References: <AM0PR08MB37160B8A021052198699CD17FAF00@AM0PR08MB3716.eurprd08.prod.outlook.com> <d90418f6-746d-0e08-1089-15bb8fe5d04d@free.fr> <MWHPR19MB1501C653DA4955BAB101C315AEDE0@MWHPR19MB1501.namprd19.prod.outlook.com> <363d6dbc-33e4-7ee6-8af3-075b0fb8a7b2@free.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <363d6dbc-33e4-7ee6-8af3-075b0fb8a7b2@free.fr>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/U2l5YA55TeTXOmTfMok4GpiVcKY>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Apr 2020 02:15:04 -0000

Hi Denis,

I am going to top-post because the quoting in this thread has become pretty
mangled.

First off, thank you for calling out the text in the document about
scenarios where "the authorization server and resource server are not
co-located, are not run by the same entity, or are otherwise separated by
some boundary"; this does indeed present some consequences for the privacy
considerations of the protocol that will need to be addressed in some
manner, though not necessarily the one that you envision.  I will try to
remember to check for this point when the document progresses to IESG
Evaluation.

You outline some interesting protocol proposals, such as letting the client
choose the token profile type, mandating (in at least some cases)
visibility into the token contents for the client, and letting the client
add additional token parameters in its request, but it seems pretty clear
to me that while these would make for an interesting protocol, that
protocol would fundamentally not be OAuth 2.0.  As such, it doesn't seem
appropriate to attempt to require them as part of this specific document.

I would also note that framing things as a contrast between "privacy by
design" and "spy by design" seems designed to evoke an emotional reaction,
and as such are actively harmful to rational technical debate.  I implore
you to focus on the facts of what data flows where and which aspects of
such flows are desirable and undesirable in the various situations under
consideration.

Finally, I'll note that though I am mostly just an observer here and not an
implementor, it's my sense that OAuth 2.0 as currently deployed involves a
relatively large number of RSes speaking to a comparable or smaller number of
ASes, and that it is common for AS implementations to have significant
amounts of logic dedicated to knowing the capabilities of the RSes they
serve.  Many of your comments do not seem consistent with this worldview,
and I invite the other WG participants to clarify if my understanding is
incorrect.

Thanks,

Ben

On Fri, Apr 10, 2020 at 11:07:35AM +0200, Denis wrote:
> 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-bounces@ietf.org> on behalf of Denis 
> > <denis.ietf@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