There are use cases where the AS can be expected to know (and in fact needs to 
know) which RSes a token will be used with, and use cases where there is value 
in obscuring this fact. This spec should not be limited to only one or the 
other. The work you suggest to support obscuring the RS identity is not unique 
to any particular access token format, and is therefore out of scope for this 
document.

Likewise, token format negotiation is an interesting concept, but by its nature 
is not bound to any specific format. If you are interested in pursuing that 
work, I suggest submitting it as a separate I-D. A JWT access token profile 
provides significant value without this addition, so I don’t see any benefit in 
trying to incorporate it into this draft.

Note that permitting the client to inspect the access token does not prevent 
the AS and RS from exchanging information about the client or resource owner, 
as this could be done via proprietary claims with encrypted values or via 
separate service-to-service interactions between the RS and AS. It should also 
be noted that in many cases (notably ones where the AS and RS are closely 
affiliated) encrypting the access token preserves the resource owner’s privacy 
by preventing the client from seeing information that the resource owner has 
shared with the AS and RS but not the client.

Lastly I am against adding a mechanism for requesting arbitrary claims to be 
included in the access token. The purpose of the access token is to serve as 
credentials that the client can use to access protected resources. If the 
client wants claims, they should request the appropriate scopes and retrieve 
them from a profile or userinfo endpoint, or use OIDC. The information required 
by the resource server should be understood by the AS based on the resource 
indicators and scopes in the request. If this is not the case, then that 
suggests there is a trust boundary between the AS and RS and therefore needs to 
make its own authorization request. Since OAuth 2.0 access tokens represent an 
authorization grant to the client, it would be inappropriate to bundle the 
resource server’s authorization request into the client’s authorization request.

–
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/


From: OAuth <oauth-boun...@ietf.org> on behalf of Denis <denis.i...@free.fr>
Date: Sunday, April 12, 2020 at 8:48 AM
To: Benjamin Kaduk <ka...@mit.edu>
Cc: Vittorio Bertocci <vittorio.berto...@auth0.com>, oauth <oauth@ietf.org>
Subject: RE: [EXTERNAL] [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for 
OAuth 2.0 Access Tokens"


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


Hi Benjamin,

Since there is tomorrow a virtual meeting and additionally I am locked down, by 
exception, I reply today.

We both agree that when 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.

Today OAuth 2.0 has not been constructed taking into consideration this case, 
i.e. it has not been designed taking into consideration
"Privacy by Design". The fact is that OAuth 2.0 has nothing specific to take 
care of privacy principles.

There would be a simple way to solve some of my concerns: to remove in the 
Introduction (Section 1) lines 7 to 10 :

   The approach is particularly common in
   topologies 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.

Let us now assume that privacy concerns would be addressed in either OAuth 2.1. 
or OAuth 3.0.

This spec. is supposed to be targeted to OAuth 2.0 but the header at the top of 
the page omits to mention it. Currently, it is :
Internet-Draft       OAuth Access Token JWT Profile           March 2020
It should rather be:
Internet-Draft       OAuth 2.0 Access Token JWT Profile           March 2020
There is however a problem to be solved now: to allow to easily distinguish 
between OAuth 2.0 JWT and future JWT versions.

In addition, there will be the need to be able to carry unsigned parameters 
associated with an OAuth 2.1. or OAuth 3.0 JWT.

An historical example was to be able to distinguish the version of a X.509 
public key certificate using a version parameter.
Something similar should be done.

Section 6 (Privacy Considerations) should be modified.

The MUST NOT (inspect the content of the access token) should be removed.

Some text, like the following text, should be added:
In topologies 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, some privacy concerns arise. For security reasons, 
some clients may want to target their access tokens
but, for privacy reasons, may be unwilling to disclose to authorization servers 
an identification of the resource servers they will access,
so that authorisation servers will be unable to know which resources servers 
are being accessed. This profile does not contain provisions
to address this case.

For data minimization, openness and transparency, some clients may want to be 
able to specify with a fine granularity which of their identity attributes
should be incorporated into an access token and may want verify that only the 
requested identity attributes have indeed been incorporated. This profile
supports a scope parameter that allows to specify in advance which identity 
attributes should be incorporated, but the semantics of this parameter
is specific to every authorisation server. Presently, there is not standardized 
way to define, with a fine granularity, which identity attributes will be
incorporated into an access token.
My last new comment remains valid: 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,



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-boun...@ietf.org><mailto:oauth-boun...@ietf.org> on behalf 
of Denis

<denis.i...@free.fr><mailto:denis.i...@free.fr>

*Date: *Thursday, April 9, 2020 at 09:26

*To: *oauth <oauth@ietf.org><mailto: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<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to