Hi Denis,
Sorry for the slow response. I had several deadlines this week and
couldn't think much farther ahead than the next one, so my INBOX fell
behind.
On Mon, May 04, 2020 at 12:36:05PM +0200, Denis wrote:
Hello Benjamin,
First of all, you don't need to use an aggressive language to state your
opinion.
I would appreciate a little more clarity on which language comes across as
"aggressive"; I was trying very hard to stick to what I see as the facts:
- many people are frustrated with these long discussions that continue to
rehash similar points and involve people having a hard time seeing each
others' worldview
- you are making proposals for changes to this document that would
represent drastic changes from previous specifications that are used by
the current document (and are drastic changes from current practice),
without acknowledging that they are in fact drastic changes to the core
protocol
Please accept my apologies for however I deviated from that goal.
I am trying to get us to a place where we can have productive discussions
and improve the quality of our protocols. Right now I don't think we're
having very productive discussions; in fact, we're holding up progress on a
document that looks likely to become widely deployed by asking it to do
more than is reasonable for it to do.
Please follow BCP 54, i.e. RFC 7154, issued inMarch 2014 with the
following title:"IETF Guidelines for Conduct". In particular:
" Regardless of these individual differences, participants treat
their colleagues with respect as persons especially
when it is difficult to agree with them: treat other
participants as you would like to be treated ".
I wrote:
(...)
I will go one step further: if the client wants to inspect the
token and
if the format of the token is unknown to the client, then the client
will simply stop its further transmission. For some clients, preserving
their
privacy may be more important than performing an access to a RS.
You responded :
That may be true, but I agree with Vittorio that this document needs to
strongly discourage clients from doing so, since they would
be**_breaking _*
*_a __protocol invariant_ if they do.
If "this may be true", then you should consider that the token
inspection by a client may be useful and thus should not be prevented.
I do in fact agree that token inspection by a client can be useful in at
least some situations. However, RFC 6749 is quite clear that "the [access
token] is usually opaque to the client". A requirement that the access
token MUST be inspectable by the client is incompatible with something that
"is usually opaque to the client".
However, there is no guarantee that it may always be performed.
I agree that this is the current state of affairs.
You are using the wording" _breaking a protocol invariant_". In which
RFC (related to OAuth) has such a "protocol invariance" been first
mandated ?
RFC 6749, per above.
I attempted to find an RFC using the wording "protocol invariant". I
found RFC 8546 (Wire Image) issued in April 2019 dealing in section 4.1
with the topic " Declaring Protocol Invariants", using the following terms:
Declaring a protocol's invariants represents a promise made by the
protocol's developers that certain bits in the wire image, and behaviors
observable in the wire image, will be preserved through the
specification of all future versions of the protocol.
Perhaps my usage of the term "protocol invariant" was confusing or
inappropriate. I meant to say that you are trying to change a property of
the core protocol specification; whether or not it is best described as an
"invariant" is immaterial to my point. In other words, a generic OAuth 2.0
client has to be prepared to deal with access tokens that are opaque to it.
Using these explanations, I have difficulties to understand how
preventing the content of a JWT to be inspected by a client may be
considered
as "a promise made by the protocol's developers that certain bits in the
wire, and behaviors observable in the wire, will be preserved
through the specification of all future versions of the protocol".
I probably missed something. Would you be able to explain ?
(I tried to above.)
A second point:
As a co-author of RFC 3161 published in August 2001 and of RFC 36268
published in November 2003 to name a few of the RFCs
to which I contributed, I am not aware of any reference to an ISO
document made into a RFC. This seems to be a common practice.
When I used the term "refer", I was not asking to place a reference to
an ISO document in this working draft but to allow everybody in
the WG to have the ability to have a look at its content (and for free).
Ah, I misunderstood you then; sorry about that.
Using readily-available documents where someone has already written down
relevant information is a great way to quick-start a discussion, but I
thought you wanted us to have this I-D accept wholesale the definitions
from the ISO document without further discussion.
Table 3 is simply a quick "reference" to ten privacy principles.
A third point:
RFC 6973 (Privacy Considerations for Internet Protocols) has been
published in July 2013. Its introduction mentions:
The guidance provided here can and should be used to _assess the privacy
considerations of protocol_, architectural,
and operational _specifications_ (...)
The guidance provided here is meant to help the thought process of
privacy analysis; it does not provide specific directions
for how to write a privacy considerations section.
Section 7 (Guidelines) mentions :
This section provides guidance for document authors in the form of a
questionnaire about a protocol being designed.
The questionnaire may be useful at any point in the design process,
particularly after document authors have developed
a high-level protocol model as described in [RFC4101].
(...)
However, by carefully considering the answers to each question, document
authors should be able to produce a comprehensive
analysis that can serve as the basis for discussion of whether the
protocol adequately protects against privacy threats.
I actually think it would be quite valuable to perform this kind of
analysis for RFC 6749 (and extensions). Its usage has evolved quite a lot
from its initial origins, and there are (as you have pointed out) many
areas that are lacking. Would you be willing to start an I-D on this
topic? I think that it would be more valuable to do something systematic
than to try to do something piecemeal for this document just because it is
a document the WG is currently working on.
An important item which is addressed both in ISO 29100 and RFC 6973 in
section 7.1 is "Data Minimization". RFC 6973 mentions:
a.*Identifiers*.What identifiers does the protocol use for
distinguishing initiators of communications?
Does the protocol use identifiers that allow different protocol
interactions to be correlated?
What identifiers could be omitted or be made less identifying while
still fulfilling the protocol’s goals?
b.*Data*.What information does the protocol expose about individuals,
their devices, and/or their device usage (other than the identifiers
discussed in (a))?
To what extent is this information linked to the identities of the
individuals?How does the protocol combine personal data with the
identifiers discussed in (a)?
c.*Observers*.Which information discussed in (a) and (b) is exposed to
each other protocol entity (i.e., recipients, intermediaries, and enablers)?
Are there ways for protocol implementers to choose to limit the
information shared with each entity? µ
Are there operational controls available to limit the information shared
with each entity?
(...)
e.*Persistence of identifiers*.What assumptions are made in the protocol
design about the lifetime of the identifiers discussed in (a)?
Does the protocol allow implementers or users to delete or replace
identifiers?
f.*Correlation*.Does the protocol allow for correlation of
identifiers?Are there expected ways that information exposed by the
protocol will be combined
or correlated with information obtained outside the protocol?
RFC 6973 also mentions in section 7.2 (User Participation) (while ISO
29100 uses the wording "Consent and choice"):
a.*User control*.What controls or consent mechanisms does the protocol
define or require before personal data or identifiers are shared or
exposed via the protocol?
All the above questions are useful to assess privacy considerations
about the protocol. Some key questions related to OAuth are the following:
* considering the current semantics of the "sub" claim, what are the
implications in terms of "correlation" ?
* considering the current semantics of the scope request parameter (or
of any other token request parameter), what are the implications in
terms of "user control" ?
I agree: these are "key questions related to OAuth". Where I perhaps
disagree with you is that I believe they are key questions relating to the
protocol as a whole; the discussion so far seems to indicate that you wish
to both perform this analysis and change the protocol all as part of the
JWT profile document. I think the tasks are better performed separately.
The next version of this document should use RFC 6973 more closely as a
guidance to "_assess the privacy considerations __of the protocol_ and
of operational _specifications_".
I fully support having privacy considerations sections that discuss the
privacy properties of the protocol in question, even including aspects that
are currently lacking.
However, I do not believe that a JWT profile for OAuth use is the place to
make changes to the core OAuth protocol that improve its privacy properties.
(If we can specify the token format in a way has better privacy properties
than alternative token formats, we should, of course, but we can't change
the protocol itself.)
Making changes to OAuth that improves its privacy properties is a laudable
goal, and I would happily read any I-Ds that proposed such protocol changes
(though I fear that the current deployment/semantics may constrain the
degree to which OAuth 2.0 can be improved and have much more hope for the
txauth group to produce a protocol with good privacy properties). The
discussion so far has not convinced me that this document is the right
document in which to do so.
Thanks,
Ben
Hi Denis,
You seem to be continuing to be operating under incorrect assuptions about
how OAuth 2.0 works, and have proceeded to make long chains of reasoning
that, unfortunately, are not based on a solid foundation. In order to
reduce the amount of frustration amongst all participants, in the future I
strongly suggest that you make sure you have the fundamentals correct
before going into long chains of reasoning.
Furthermore, while you have indeed identified some areas where the current
OAuth ecosystem could be improved, I reiterate that the current document,
defining a token format that is optional to use, is not the place to make
changes to how OAuth works. I think you do everyone a disservice for
attempting to suggest that this document should do so.
Because there is so much based on a flawed foundation, I will not respond
inline to every point, but do see a few things where further clarification
would be useful.
On Thu, Apr 30, 2020 at 11:50:04AM +0200, Denis wrote:
Hello Vittorio,
Your reply was amazingly fast. Responses are between the lines.
Thanks Denis for the thorough commentary.
/> The title of this spec./
Fixed, thanks!
/> The client MUST NOT inspect the content of the access token/
This is really a sticky point. I really want to acknowledge your PoV
on this, but at the same time I found this to be one of the biggest
sources of issues
in the use of JWT for access tokens hence I feel we really need to
give solid guidance here. Let me expand further on the reasoning
behind it,
and perhaps we can get to language that satisfies both PoVs.
To me the key point is that clients should not write /code/ that
inspects access tokens. Taking a dependency on the ability to do so is
ignoring fundamental information
about the architecture and relationships between OAuth roles, and
suggests an ability of the client to understand the semantic of the
content that cannot be assumed
in the general case. I expanded on the details in my former reply to
you on this topic, I would recommend referring to it.
Clients violating this simple principle has been one of the most
common sources of production issues I had to deal with in the past few
years, and one of the hardest
to remediate given that clients are hard to update and sometimes the
things they relied on were irremediably lost. This is why I am
inclined to put in here strong language.
That said: I have nothing against client developers examining a
network trace and drawing conclusions based on the content of what
they see. That doesn’t create any hard
dependencies and has no implications in respect to changes in the
solution behavior. However I am not sure how to phrase that in the
specification, given that referring
to the client inevitably refers to its code. I am open to suggestions.
First of all, a "*MUST NOT* "should not be placed in a privacy
considerations section, but in the main body of the document.
The goal of a privacy considerations section is to provide explanations,
but not to introduce additional requirements.
That's not actually a requirement. In many cases it makes sense to avoid
putting normative requirements in the security and/or privacy
considerations sections, but it is very much a thing that is done in many
RFCs, and in some cases it is useful to do so.
Then after, since this section is about privacy considerations, it is
important to refer to an ISO standard that has been published 9 years ago.
Is it? I don't see much precedent for IETF documents referencing this ISO
standard. If it's so important you'd think that we'd have been citing it
with regularity. Since this will be the first or second time, I think you
need to provide some additional justification as to how the topics it
covers fit within the existing IETF BCPs for how we treat security and
privacy considerations before we conclude that it is the appropriate
reference.
It is ISO 29100 (Information technology — Security techniques — Privacy
framework). Most of the ISO standards need to be bought.
However, there are a few exceptions and this standard can be freely
downloaded from the ISO web site, if you accept some conditions,
using this URL:
https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
ISO 29100, even if it is outdated on some aspects (it only deals with
two entities), identifies ten principles (See Table 3).
1. Consent and choice
2. Purpose legitimacy and specification
3. Collection limitation
4. Data minimization
5. Use, retention and disclosure limitation
6. Accuracy and quality
7. Openness, transparency and notice
8. Individual participation and access
9. Accountability
10. Information security
11. Privacy compliance
If the client is unable to inspect the token, then openness and
transparency do not exist any more.
Since there is no formal protocol in OAuth 2.0 for "consent and
choice", the only way for a client for denying its consent is to inspect
the token
and to stop its transmission if the content of the token is not
considered to be adequate for it.
Since you are open to suggestions, would you please reconsider the text
I proposed: it simply states that if the client wants to inspect the token,
it will not necessarily be in a position to do it. It is simply a
warning, but this warning does not prevent the client to attempt to
inspect the token .
I will go one step further: if the client wants to inspect the token and
if the format of the token is unknown to the client, then the client
will simply
stop its further transmission. For some clients, preserving their
privacy may be more important than performing an access to a RS.
That may be true, but I agree with Vittorio that this document needs to
strongly discourage clients from doing so, since they would be breaking a
protocol invariant if they do.
Thanks,
Ben
3)…
I have a pretty hard time following the chain of reasoning in this
section. Let me attempt to tackle it to the best of my understanding.
I think the key might be
/> a client should be able to choose whether it wishes the sub claim
to contain [..]
/
I don’t think that should be a choice left to the client. In business
systems, my experience is that the type of identifiers to be used
(when the IdP gives any choice at all)
is established at resource provisioning time. I am not aware of
mechanisms thru which a client signals the nature of the identifier to
be used, nor that would be fully
feasible (the resource knows what it needs to perform its function).
Consent and choice is the first of the ten privacy principles. Since
OAuth has not been constructed taking into considerations this privacy
principle,
it is quite "normal" that you don't observe protocols able to do it at
the present time.
Furthermore:
/> which has nothing to do with uniqueness since the value changes for
every generated token.
/
Again, this is something that was touched on in my former reply to
your message. As long as an identifier identifies one resource only,
it satisfies uniqueness. It doesn’t have to be a singleton.
It is a matter of interpretation. I stick to the definition given in RFC
7519 (section 4.1.2):
*T**he subject value MUST either be scoped to be locally unique in the
context of the issuer or be globally unique.*
However, the "context of the issuer" is left undefined.
Finally, the scope is optional (for good reasons: 1^st party and non
delegation scenarios don’t require it) hence it cannot be relied upon
for properties that should hold in every scenario.
I would not say that the scope request parameter is a nice way to choose
which attributes should be placed in a JWT. However, considering the
limitations placed
in this document, it is the ONLY way to do. In my email sent before the
virtual meeting, I wrote: "Allowing a client to only specify a scope and
a resource is very restrictive".
Clause 2.2.2 (second paragraph) states:
***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.
Currently, the client has no control of the claims that will be placed
in a JWT and further more the current wording of privacy consideration
section
prevents the client to have any inspection of the attributes that have
been placed in a JWT. Privacy principles 1 and 7 from ISO 29100 are not
fulfilled.
There are more implications. If, in the future, a mechanism is defined
to allow the client to choose the type of the attributes that should be
placed in a JWT,
then the "sub" claim is insufficient. Taking into consideration my
previous email, four types of attributes types would need to be specified:
The client should be able to choose whether it wishes a claim that contains:
* a global unique identifier for all ASs ("globally unique"),
* a unique identifier for each AS ("locally unique in the context
of the issuer"),
* a different pseudonym for each RS, or
* a different pseudonym for each authorization token request.
Clause 2.2.2 states:
* 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.
I don't believe this is true in general. Considering its privacy
preferences, only the client may know what is appropriate: not the AS,
neither the RS.
In summary: per the preceding thread on this topic, the consensus was
that varying the sub content was a satisfactory way of protecting
against correlation.
"/if all you have is a hammer, everything looks like a nail/".
When the only parameter that can be used is the "sub" claim, then the
only solution is to place everything into it.
I don’t a gree that clients should have a mechanism to request
different sub flavors, as that decision should be done out of band by
the AS and RS; and the scope isn’t always available anyway.
While it would be nice to have such a mechanism, we are not going to
define such a mechanism during a second WGLC.
The privacy considerations section should only inform the readers about
the limitations of the protocol in terms of privacy.
I have proposed text to address the point. If you would prefer a
different wording to address this point, please make another proposal.
/> targeting of access tokens/
Let me think about that a bit longer.
I acknowledge that the decision of including an audience has the
effect of letting the AS track when the client accesses a particular
resource,
but at the same time that’s completely mainstream and very much by
design in a very large number of cases. As such, I find the language
you are suggesting to be potentially confusing, as it positions this
as an exception vs a privacy protecting mainstream that is in fact not
common,
and ascribes to the client more latitude than I believe is legitimate
to expect or grant.
I’ll try to come up with concise language that clarifies to the reader
that the current mechanism does allow AS tracking.
Please do so.
Denis
*From: *OAuth <oauth-boun...@ietf.org> on behalf of Denis
<denis.i...@free.fr>
*Date: *Wednesday, April 29, 2020 at 09:12
*To: *"oauth@ietf.org" <oauth@ietf.org>
*Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
for OAuth 2.0 Access Tokens"
You will find four comments numbered 1) to 4).
*1) *The title of this spec. is:
JSON Web Token (JWT) Profile for OAuth *2.0* Access Tokens
So, this spec. is supposed to be targeted to OAuth *2.0. * However,
the header at the top of the page omits to mention it.
Currently, it is :
Internet-Draft OAuth Access Token JWT Profile April 2020
It should rather be:
Internet-Draft OAuth *2.0* Access Token JWT Profile April 2020
*2)* The following text is within section 6.
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 (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.
Nonetheless, authorization servers should
not assume that clients will comply with the above.
It is of a primary importance that clients MAY be able to inspect
tokens before transmitting them.
The "MUST NOT" is not acceptable.
The above text should be replaced with:
Reading the access token content may be useful for the user to verify
that
the access token content matches with its expectations. However,
the authorization server and the resource server might decide to
change the
token format at any time. Thus, the client should not expect to
always be
in a position to read the access token content.
The remaining of the text about this topic is fine.
*3) *The next topic is about the sub claim.
The text states:
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.
I have a set of questions:
1. How can authorization servers choose how to assign sub values
according to the level of privacy required "by each situation" ?
2. How can authorization servers know the level of privacy required
"by each situation" ?
3. How can the users be informed of the level of privacy required "by
each situation" ?
4. How can the users *consent* with the level of privacy required "by
each situation" ?
Currently, the request MUST include either a resource parameter or an
aud claim parameter, while it MAY include a scope parameter.
The syntax of the scope parameter is a list of space-delimited,
case-sensitive strings (RFC 6749). It is thus subject to private
agreements
between clients and Authorization Servers. Since the scope is being
returned, it is a primary importance that the returned scope matches
with its expectations before transmitting the token to a Resource Server.
In theory, a client should be able to choose whether it wishes the sub
claim to contain :
* a global unique identifier for all ASs ("globally unique"),
* a unique identifier for each AS ("locally unique in the context of
the issuer"),
* a different pseudonym for each RS, or
* a different pseudonym for each authorization token request.
The only variable parameter that it can use for this purpose in the
token request is the scope parameter.
RFC 7519 states is section 4.1.2:
The subject value MUST either be scoped to be locally unique in the
context of the issuer
or be globally unique.
It is quite hard to recognize that the sub claim is able to carry a
different pseudonym for each RS, i.e. for case (c), or
a different pseudonym for each authorization token request, i.e. for
case (d), which has nothing to do with uniqueness
since the value changes for every generated token.
This has implications about the following text:
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.
Since it addresses case (c).
and also about the following text:
4.b) 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.
Since it addresses case (d).
This means that the current text placed in the privacy considerations
section was a good attempt to address the case,
but that the text needs to be revised.
Proposed text replacement for all the previously quoted sentences:
According to RFC 7519 (4.1.2): The subject value MUST either be scoped
to be locally unique in the context of the issuer or be globally unique.
When the sub claim contains a globally unique identifier, this allows
to correlate principal activities across multiple resource servers,
while in addition,
this globally unique identifier may also allow to correlate the
principal activities on servers where no access has been performed by
the principals
to these servers but where the same globally unique identifiers are
being used by these servers.
When the sub claim contains a locally unique identifier in the context
of the issuer, this also allows the tracking of principal activities
across multiple resource servers.
The scope request parameter is the only way to influence on the
content of the sub claim parameter. Its meaning is subject to a
private agreement
between the client and the AS, which means that the use of the scope
parameter is the only way to choose between a locally unique identifier
in the context of the issuer or a globally unique identifier.
Since the scope parameter is being returned, it is a primary
importance that the returned scope matches with the expectations of
the client before transmitting
the token to a Resource Server.
However, there are other cases where the client would like to be able
to choose whether it wishes the sub claim to contain :
- a different pseudonym for each RS so that different resource
servers will be unable to correlate its activities, or
- a different pseudonym for each authorization token request, so
that the same resource server cannot correlate its activities
performed at different instant of time.
Considering the semantics of the sub claim, these two cases cannot be
currently supported.
*4) *The next topic is about the targeting of access tokens
Text had been proposed before the last conference call. Then, the
topic has been presented at the very end of the last conference call,
but no text has been included
in the next draft.
Here is a revised text be included in the privacy considerations section:
For security reasons, some clients may be willing to target their
access tokens but, for privacy reasons, may be unwilling to disclose
to Authorization Servers
an identification of the Resource Servers they are going to access, so
that Authorization Servers will be unable to know which resources
servers are being accessed.
The disclosure of the Resource Servers names allows the Authorization
Servers to list all the Resource Servers being access by all its users
and in addition to list pairs
of (Principal, Resource Servers) which allow to trace all the users
accesses to Resource Servers performed through a given Authorization
Server. When a token is targeted,
this profile does not contain provisions to address these two threats.
Denis
Hi all,
This is a second working group last call for "JSON Web Token (JWT)
Profile for OAuth 2.0 Access Tokens".
Here is the document:
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06
Please send your comments to the OAuth mailing list by April 29, 2020.
Regards,
Rifaat & Hannes
_______________________________________________
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
