Hello Vittorio,
I have three comments numbered 1, 2 and 3.
*Comment 1:**
*
Section 3 states:
3. Requesting a JWT Access Token
An authorization server can issue a JWT access token in response
to any authorization grant defined by [RFC6749] and subsequent
extensions meant to result in an access token.
If the request includes a "resource" parameter (as defined in
[RFC8707]), the resulting JWT access token "aud" claim SHOULD have
the same value as the "resource" parameter in the request.
I had a discussion I had on the mailing list with Hannes on September 10:
[Denis] I believe, it would be worthwhile to add a sentence, just
after this sentence, with the following text:
When an authorization server decides to issue a JWT access token
compliant to this profile, then the following requirements apply.
(...)
[Hannes] That’s fine for me because this is what the intended effect
of the spec is.
This portion of text from section 3 should be changed into:
3. Requesting a JWT Access Token
An authorization server can issue a JWT access token in response
to any authorization grant defined by [RFC6749] and subsequent
extensions meant to result in an access token.
*When an authorization server decides to issue a JWT access token
compliant to this profile, then the following requirements apply. *
If the request includes a "resource" parameter (as defined in
[RFC8707]), the resulting JWT access token "aud" claim SHOULD have
the same value as the "resource" parameter in the request.
*Comment 2:**
*
Section 6 states:
6. Privacy Considerations
As JWT access tokens carry information by value, it now becomes
possible for clients and potentially even end users 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 (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.
RFC 2119 defines the meaning of MUST NOT or SHOULD NOT:
2. *MUST NOT* This phrase, or the phrase "SHALL NOT", mean that
the definition is an absolute prohibition of the specification.
(...)
4. *SHOULD NOT* This phrase, or the phrase "NOT RECOMMENDED" mean
that there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing
any behavior described with this label.
The first sentence of section 6 recognizes that it is technically
possible for clients and potentially even end users to directly peek
inside the token claims collection.
There may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but there is no
assurance that this can be done
since the authorization server and the resource server might decide to
change the token format at any time.
The sentence :
The client *MUST NOT* inspect the content of the access token:
should be changed into:
The client *SHOULD **NOT* inspect the content of the access token:
*Comment 3:**
*
Section 6 also state:
This profile mandates the presence of the "sub" claim in every JWT
access token, making it possible for resource servers to rely on that
information for correlating incoming requests with data stored
locally for the authenticated principal. Although the ability to
correlate requests might be required by design in many scenarios,
there are scenarios where the authorization server might want to
prevent correlation. The "sub" claim should be populated by the
authorization servers according to a privacy impact assessment. For
instance, if a solution requires preventing tracking principal
activities across multiple resource servers, the authorization server
should ensure that JWT access tokens meant for different resource
servers have distinct "sub" values that cannot be correlated in the
event of resource servers collusion. Similarly, if a solution
requires preventing a resource server from correlating the
principal’s activity within the resource itself, the authorization
server should assign different "sub" values for every JWT access
token issued. In turn, the client should obtain a new JWT access
token for every call to the resource server, to ensure that the
resource server receives different "sub" and "jti" values at every
call, thus preventing correlation between distinct requests.
As already mentioned on this mailing list, the above sentences would
modify the semantics of the "sub" claim.
While reading RFC 7519, no reader may be able to figure out that
there are more than two flavours of the "sub" claim.
This draft would be introducing two new other favours of the
semantics of the "sub" claim which are not present in RFC 7519.
When an element has been defined, its semantics cannot be changed
... unless making an Errata to RFC 7519 which would be
a clean way to proceed.
RFC 7519 defines the sub claim in the following way:
4.1.2. "sub" (Subject) Claim
The "sub" (subject) claim identifies the principal that is the
subject of the JWT. The claims in a JWT are normally statements
about the subject. *The subject value MUST either be scoped to
be locally unique in the context of the issuer or be globally unique.*
The processing of this claim is generally application specific.
The "sub" value is a case-sensitive string containing a StringOrURI
value. Use of this claim is OPTIONAL.
Change into:
This profile mandates the presence of the "sub" claim in every JWT
access token, making it possible for resource servers to rely on
that information for correlating incoming requests with data stored
locally for the authenticated principal. The "sub" claim is scoped
to be either locally unique in the context of the issuer or be
globally unique (see section 4.1.2 from RFC 7519).
When the "sub" claim is scoped to be locally unique in the context
of the issuer, in the event of resource servers collusion, it can be
used to correlate principals.
When the "sub" claim is scoped to be globally unique, in the event of
resource servers collusion, it can be used to correlate principals not
only between resource servers
but it can also be used to correlate principals between resource
servers and other servers that do not implement this protocol but are
using the same globally unique identifiers.
Denis
Thanks Brian, Logan.
On clarity. I tweaked that section and produced a new draft (-10).
Details:
* Formally, the fact that we are referring to the User entity should
be unambiguous. 4.1.2 is a subsection of 4.1, which is titled
"User Resource Schema”.
However as a frequent critic of the excessive cyclomatic
complexity of the specs, I am making myself guilty of precisely
the same sin 😊 your suggestion can save the reader the need to
follow and parse the reference to understand the situation, hence
it’s a good improvement to clarity.
* For what concerns the actual format of the claims. The groups
entity actually appears as non-normative example in
https://tools.ietf.org/html/rfc7643#section-8.2; I can make an
explicit reference to that and make things a bit more discoverable.
* For roles and entitlements, things are murkier.
Before embarking in this endeavor I too had the expectation that
this would be a flat list of strings, but digging a bit in
existing implementations it turns out that’s not necessarily the
case. For example, Slack SCIM represents individual roles as two
possible forms { “value”:<name>, “primary”; <bool>}| {
“value”:<name>}, whereas databricks uses{ “value”:<name>}; WSO2
uses{ “value”:<name>, “type”; <enum>}.
So for those two I don’t think we can do better than the current
statement about SCIM not supplying a vocabulary for them.
* I had some issues w the references where the section links were
turned into local links, as it happened in the past. That should
be fixed too.
* I applied the “” notation to the attributes, given that we are
turning them into claims it seems clearer to sue the same
typographic concention.
* side note… <nonexistent section reference>
Excellent point, fixed.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
