[OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-iss-auth-resp-03: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-iss-auth-resp-03: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/
--
COMMENT:
--
Is the authorization endpoint the only one that would benefit from the
added "iss" protection? Should we say anything about the utility of the
"iss" parameter in other responses?
Section 2
If the authorization
server provides metadata as defined in [RFC8414], the value of the
parameter iss MUST be identical to the authorization server metadata
value issuer.
Does it ever make sense to implement this document but not provide
metadata as in RFC 8414? Should this document give any guidance (e.g.,
SHOULD or MUST) about also implementing RFC 8414 if this document is
implemented?
Section 2.1
Thank you for using a nice random code with 256 bits of entropy in the
example :)
Section 2.2
Should we use a different 'state' value for the example successful
response and example error response?
Section 2.3
* The issuer identifier included in the server's metadata value
issuer MUST be identical to the iss parameter's value.
I think we attempted to impose this requirement using the BCP 14 MUST
keyword up in toplevel section 2 as well. Generally my advice is to
only use the normative keywords in one place for any given requirement,
to avoid any risk of conflicting guidance that could lead to different
implementation behaviors. (In this case, putting the MUST here seems to
make more sense, since it's an explicit listing of "the following rules
apply".)
NITS
Section 2.4
If clients interact with both authorization servers supporting this
specification and authorization servers not supporting this
specification, clients MUST store the information which authorization
server supports the iss parameter. Clients MUST reject authorization
I think there's a missing word here, for "the information about" or even
a broader rewording to "MUST retain state about whether each
authorization server supports the iss parameter".
support in their metadata. Local policy or configuration can
determine whether to accept such responses and specific guidance is
out of scope for this specification.
I'd suggest s/whether/when/, since we already do give default guidance
("SHOULD discard") earlier.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-par-08: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-par-08: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-par/
--
COMMENT:
--
I made a github PR with some editorial suggestions, at
https://github.com/oauthstuff/draft-oauth-par/pull/70 .
Section 1
Those apps typically invoke a
custom tab with an URL that is translated into a GET request. Using
"POST" would require the app to first open a web page under its
control in the custom tab that in turn would initiate the form "POST"
towards the authorization server. PAR is simpler to use and has
additional security benefits as described above.
This description leaves me with a feeling that I only have an incomplete
picture of why POST is "prohibitively difficult" to use with mobile
apps. It seems like the setup is describing a scenario where the
authorization logic is operating inside a framework or environment
provided by some other entity that is unwilling or unable to change the
framework to accomodate new OAuth behavior. Is this other entity the
author of the mobile app, or an app framework, or somethint else?
Having a bit more description of the multiple entities involved and
which one is trying to control the specific mechanics of the
authorization request would make this depiction a more compelling
argument that POST is unusable.
Section 1.1
POST /as/par HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
My personal preference would be to have examples that just want a
generic HTTP authentication mechanism to use something stronger than
Basic, though I don't think this is something that I can insist on, at
present. (Applies throughout.)
HTTP/1.1 201 Created
Cache-Control: no-cache, no-store
Content-Type: application/json
{
"request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2",
"expires_in": 90
}
The "request_uri" element's semantics feels like a very natural fit for
the native HTTP "Location" response header field (vs requiring a
specific element in the JSON body of the response). I am less sure that
there's a native HTTP element for the expiration time, as the HTTP
timeouts tend to be associated with HTTP caching vs the actual lifetime
of the resource.
Section 2
It feels a little unfortunate that we have to reuse the metadata
parameters relating to the token_endpoint_auth_method for PAR, but
creating new metadata parameters that are basically always going to hold
the same values is probably worse...
Section 2.1
Any token endpoint parameters that are not related
to client authentication have no defined meaning for a pushed
authorization request. [...]
I suppose that in most cases, whether or not a token endpoint parameter
is related to client authentication should be fairly unambiguous ... but
the registry at
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters
has a dedicated column for "parameter usage location". It seems like it
would be fairly straightforward to add "pushed authorization request" as
an additional possible value there and remove the ambiguity. We could
enumerate the existing parameters that are applicable and update the
references for the registry to include this document.
Section 2.1
The authorization server MUST process the request as follows:
We often see descriptions along the lines of "this is not intended to
constrain implementation techniques; any procedure that results in an
equivalent outcome is permissible". This procedure is simple enough
that we may not need to have concerns of that nature, though.
Section 2.2
* "request_uri" : The request URI corresponding to the authorization
request posted. This URI is used as reference to the respective
request data in the subsequent authorization request only. [...]
Would it be appropriate to use the phrase "single-use" in this
description?
Section 2.4
It is at the discretion of the authorization server to apply
restrictions on supplied "redirect_uri" values, e.g. the
authorization server MAY require a certain URI prefix or allow only a
query parameter to vary at runtime.
Is this expected to be discoverable by the client? Would there be a
particular error code used, for example?
Section 3
[OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwt-introspection-response-11: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-jwt-introspection-response-11: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/
--
COMMENT:
--
Thank you for addressing my Discuss (and Comment) points!
Just a couple final notes on the -11:
Section 4
Please double-check that describing the resource server as
"authenticating with a private-key JWT" is compatible with using the
urn:ietf;params:oauth:client-assertion-type:jwt-bearer assertion type.
I am not up-to-date on the precise semantics of that assertion type, offhand.
Section 5
Token introspection response parameter names intended to be
used across domains SHOULD be registered in the OAuth Token
Introspection Response registry
[IANA.OAuth.Token.Introspection] defined by [RFC7662].
I'm a bit surprised to see any normative terminology used on the
question of whether response parameter names are to be registered, since
RFC 7662 already has a requirement ("MUST") for this scenario. If the
intent truly is to weaken the requirement from RFC 7662, it seems that
some additional clarification is in order that this is a change from the
existing specification and why it is a desirable change.
(The "MAY extend the token introspection response" in the preceding
paragraph, not quoted, is also already present in RFC 7662.)
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-access-token-jwt-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ -- COMMENT: -- Section 2.1 JWT access tokens MUST include this media type in the "typ" header parameter to explicitly declare that the JWT represents an access token complying with this profile. Per the definition of "typ" in Section 4.1.9 of [RFC7515], it is RECOMMENDED that the "application/" prefix be omitted. [...] Just to check: is the reason this is only RECOMMENDED just because that's the requirement level that RFC 7515 used? AFAIK we can be more stringent here and just always require it to appear as "at+jwt", to simplify processing, if that is compatible with existing deployments (or we are willing to declare them non-conformant). (Section 4 would change accordingly if this text changes.) Section 2.2 Why does "iat" get an extra sentence describing the claim in addition to "as defined in [reference]" but not iss/exp/jti/etc.? Section 2.2.1 response (e.g., via the implicit flow) or after one or more token exchanges (e.g., obtaining a fresh access token using a refresh token, or exchanging one access token for another via [RFC8693]). nit: RFC 8693 doesn't effectuate token exchange; the protocol it specifies does. So "via the token exchange mechanism of [RFC8693]" or "via [RFC8693] procedures" or such seems more grammatically correct. Section 2.2.2 Any additional identity attribute whose semantic is well described by an entry in the JSON Web Token (JWT) IANA registry introduced in [RFC7519] SHOULD be encoded using the corresponding claim name. Note that the JWT IANA registry includes the claims found in Section 5.1 of [OpenID.Core]. I assume that ths "SHOULD be encoded using the corresponding claim name" just refers to the claim name used, and is not advising that all identity attributes be always included. If so, perhaps a few more words would help clarify, such as "if that attribute is to be included in the JWT access token" at the end of the sentence. Semantically it would also work to start the sentence with "when being included", but IMO that would detract from the focus of the sentence. Authorization servers including resource owner attributes in JWT access tokens should exercise care and verify that all privacy requirements are met, as discussed in Section 6. I'd suggest to s/should/need to/. Section 2.2.3 All the individual scope strings in the "scope" claim MUST have meaning for the resources indicated in the "aud" claim. See Section 5 for more considerations about the relationship between scope strings and resources indicated by the "aud" claim. ["aud" vs "resource?] Section 2.2.3.1 An authorization server wanting to include such attributes in a JWT access token SHOULD use as claim types the "groups","roles" and "entitlements" attributes of the "User" resource schema defined by Section 4.1.2 of [RFC7643]). I do see that we go on to clarify that we register JWT claims for "groups", "roles", and "entitlements" and recommend encoding guidance for the values of these claims, but I'm still stumbling over the phrase "claim types" here. What is a "claim type"? I suspect from context that it is meant to refer to a "claim name" as recorded in the JWT Claims registry, but I'm not 100% certain. It might also help readability to split this into two sentences: "use as claims [list]. The semantic contents of these claims are desribed in their definitions as attributes of [...]", since the current wording has me trying to use "attributes" in a JWT context, but it's intended to clarify the RFC 7643 reference. Authorization servers SHOULD encode the corresponding claim values according to the guidance defined in [RFC7643]. In particular, a Why is this only a "SHOULD"? We are defining these JWT claims, so we can nail down exactly what they contain. non-normative example of "groups" attribute can be found in Section 8.2 of [RFC7643]. No specific vocabulary is provided for "roles" and "entitlements". Similarly, we may want to be more concrete about "roles" and "entitlements" if we don't already later in this document. Section 3 This section is titled "Requesting a JWT Access Token" but the contents don't really seem to provide a procedure for specifically requesting a JWT access token. (nit)
[OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-32: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-jwsreq-32: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
--
COMMENT:
--
Thank you for the new security considerations text in Sections 10.7 and
10.8 since I last reviewed; it does a great job capturing my comments
(and the current deployed reality).
Thanks also to Watson Ladd for the latest secdir review and the authors
for their responses to it.
Section 6.2
The Authorization Server MUST validate the signature of the JSON Web
Signature [RFC7515] signed Request Object. The signature MUST be
validated using a key associated with the client and the algorithm
specified in the "alg" Header Parameter. [...]
The last version I reviewed had some language tying the algorithm used
for verification back to a registration (and I commented that perhaps a
registration might not always exist). This language seems to set the
recipient up to blindly use the "alg" header parameter, even if it's
"none", and we should probably have some hedging language here (I see we
do have language elsewhere that bans "none" specifically)...
If a "kid" Header Parameter
is present, the key identified MUST be the key used, and MUST be a
key associated with the client. Algorithm verification MUST be
performed, as specified in Sections 3.1 and 3.2 of [RFC8725].
... and maybe that would just take the form of swapping the order of
these two sentences, now that I keep reading.
Section 10.2
Do any of the procedures listed for steps (c) and/or (d) need to be
performed in step (e) as well? (In particular, the requirements on the
returned URI seem like they would still apply, and possibly the need for
client authentication.
Section 10.3
Nat's response at
https://mailarchive.ietf.org/arch/msg/oauth/hB_ON_BR0fDf3NSDFcFo5MwbZ2Y/ to my
previous review suggested that there might be value in future work that
specifies the linkage across these endpoints to try to address the
cross-phase attacks discussed in [FETT]. However, the paragraph that I
had commented on (that mentions "an extension specification") has since
been removed, and I failed to track down why just from a quick
mailarchive search. There may well have been a good reason for removing
it (and the reference to [FETT]), so please help refresh my memory if
that's the case.
Section 10.4
The introduction of "request_uri" introduces several attack
possibilities. Consult the security considerations in Section 7 of
RFC3986 [RFC3986] for more information regarding risks associated
with URIs.
My previous comments had mentioned that because of time skew the
dereferenced request URI might actually have the contents of a different
request than the one intended, and Nat's response at
https://mailarchive.ietf.org/arch/msg/oauth/hB_ON_BR0fDf3NSDFcFo5MwbZ2Y/
pointed out that OIDC actually does use a nonce that would prevent such
an occurrence. Hopefully Nat did get a chance to think about whether
there was anything else that we should mention in this document, on this
topic. ("There isn't anything else to mention here" is a fine answer; I
just wanted to close the loop on that thread, since I didn't find one in
the mail archive.)
Section 11.1
nit: s/TFP/trusted third-party service/ (multiple instances), since we
stopped using "Trust Framework Provider" in the main body.
Sction 14.1
Not your fault, but BCP 195 now includes both RFC 7525 and RFC 8996 --
thank you for referencing it as BCP 195! I expect the RFC Editor will
catch the new reference if you don't want to figure out how to notate it
properly.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-10: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-jwt-introspection-response-10: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/
--
DISCUSS:
--
We've made a lot of progress at unravelling the gnarly issues relating
to merging the introspection response and JWT claims namespaces, which
is good. That said, I'd still like to discuss a little bit more the
behavior described in Section 5, where the "token_introspection" claim
in the response can also contain JWT claims (''' In addition, claims
from the JSON Web Token Claims registry [IANA.JWT] established by
[RFC7519] MAY be included as members in the "token_introspection"
claim.''') That seems to be granting carte blanche to do the thing that
was deemed problematic, i.e., mix the namespaces. As such, the current
formulation in the document, in the general case of independent
uncoordinated implementations, seems to admit the prospect of an AS
adding something to an introspection response under the guise of the JWT
claim exception that is interpreted by the recipient RS as a new
introspection response parameter (or, I think, vice versa). Yes, this
would require conflicting registrations to occur, but we still don't
have a procedure in place that would prevent such conflicting
registrations from occurring in the future. How can we add some
low-cost safety controls that mitigate the risk while still enabling the
desired functionality?
I have a couple thoughts on this: there is already an exception for
implementation/service-specific (unregistered) claims in the
introspection response, which could apply to JWT claims under the same
requisite conditions of administrative control, if that's going to cover
the scenarios in question. One could also imagine a new registration
procedure for introspection response parameters whereby (for example)
any non-conflicting value already registered as a JWT claim can be
mechanically propagated into the introspection response registry
potentially just by IANA without even expert review. Then we would just
require the contents to be registered introspection response parameters,
and someone who wants to use JWT claims can trivially get them
registered before using them.
--
COMMENT:
--
I'm not balloting this at a DISCUSS-level, because it may just be me
failing to understand the intended meaning (or being forgetful), but I'm having
a hard time
seeing how we're self-consistent about the requirement for an RS to
authenticate and authorize a given RS for a given introspection
transaction. In particular, in Section 3 we see that "the authorization
server MUST be able to identify, authenticate and authorize resource
servers" and that "[t]he authorization server MUST be able to determine
whether an RS is the audience for a particular access token and what
data it is entitled to receive, otherwise the RS is not authorized to
obtain data for the access token". While I see that there is also some
discussion about using the "scope" parameter of the token being
introspected as an indicator of the RS it is to be used for (and thus
the identity of the RS that would legitimately be making an
introspection request), and I also see discussion of using an encrypted
introspection response as a way to ensure that the contents are only
viewable by the intended RS, I'm not sure how clearly either (or both)
mechanisms constitute "authentication" of the introspection request.
Since we already require a "strong two-way trust relationship", it's not
clear to me that it would be difficult to strongly authenticate the
actual introspection request itself or that there is much gained by
skipping such a check in favor of other mechanisms. Several of my
inline comments touch on this topic (on the assumption that there is a
strong MUST for strong authentication); I left them in place to benefit
from the context of where they appear, rather than constructing a
laundry list of all of them. That said, it will suffice to explain how
I'm wrong/confused just once; there's no need to repeat it at each place
I bring up the topic.
Section 3
To support encrypted token introspection response JWTs, the
authorization server MUST also be provided with the respective
resource server encryption keys and algorithms.
That seems more of a
[OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-jwsreq-26: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
--
COMMENT:
--
[updated to note that, per
https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0eaE/
and the JWT BCP (RFC 8725), some discussion of why explicit typing is not used
would be in order]
Thanks for the many updates as we worked through the issues.
Let's also add a note about "whose JWT Claims Set holds the JSON encoded
OAuth 2.0 authorization request parameters" to the definition of Request
Object in Section 2.1 (in addition to the note in the Introduction); my
apologies for not including that when I suggested the change to the
Introduction.
Please update the Content-Length in the example in Section 5.2.3.
Section 4
The client determines the algorithms used to sign and encrypt request
objects. This decision can be based on metadata the client
registered via dynamic client registration [RFC7591] using the
parameters "request_object_signing_alg",
"request_object_encryption_alg", "request_object_encryption_enc" as
defined in the the IANA "OAuth Dynamic Client Registration Metadata"
registry [IANA.OAuth.Parameters] established by [RFC7591].
I had to read this ("this decision can be based on [...]") a few times
to understand it. If I understand correctly, the idea is that the
client will register with the AS the keys it will use for constructing
the JAR, and in that way the AS has a binding from JAR-signing key to
the specific client and request. So it's true that the decision of what
key to use "can be based on" the metadata that the client registered, in
that deciding to use a different key than the registered one(s) is
likely to cause the AS to reject the request, but that's perhaps not the
main point. Would it work to instead just say that "The keys used to
sign and encrypt request objects (and thus, the algorithms that can be
used with those keys) can be registered via dynamic client registration
[...]"?
Section 5.2
The contents of the resource referenced by the URI MUST be a Request
Object, unless the URI was provided to the client by the
Authorization Server. The "request_uri" value MUST be either URN as
defined in RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of
RFC7230 [RFC7230] . The "request_uri" value MUST be reachable by the
Authorization Server.
I defer to my ART-area colleagues, but I'm not sure what it means for a
URN URI to be "reachable"; is this requirement intended to only apply to
the "https:" case?
Section 5.2.1
It is possible for the Request Object to include values that are to
be revealed only to the Authorization Server. As such, the
"request_uri" MUST have appropriate entropy for its lifetime. For
Is there a good reference for what the lifetime of such a request might
be? Perhaps I've been reading too much of GNAP, but my intuition is
that much of the time these requests will be single-use, and I don't
have as clear of a picture for when they might persist longer. There
are also potential security considerations for long-lived request
objects, in terms of making sure that there is a binding between the
client's intent to use a given request object for a given request, the
user's authorization, etc.
Section 5.2.3
(side note) I'd consider updating the timestamps in the example response
(and perhaps moving to Apache 2.4+ as well?).
Section 6.x
(nit) I suggest consistency in subsection headings, so, e.g., "JWE
Encrypted Request Object" and "JWS Signed Request Object".
Section 6.2
The Authorization Server MUST perform the signature validation of the
JSON Web Signature [RFC7515] signed request object. For this, the
"alg" Header Parameter in its JOSE Header MUST match the value of the
pre-registered algorithm. The signature MUST be validated against
the appropriate key for that "client_id" and algorithm.
This text suggests that pre-registration is mandatory, whereas up in
Section 4 the client's choice of algorithm was merely something that
"can be based on [metadata registered via dynamic registration]". I
know that dynamic registration is not the only kind of registration
possible, but we may want to wordsmith one (or both) location to improve
the consistency.
Section 6.3
I'd suggest reiterating here the requirement to verify "client_id"
consistency between Request Object and request
[OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-jwsreq-26: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
--
COMMENT:
--
Thanks for the many updates as we worked through the issues.
Let's also add a note about "whose JWT Claims Set holds the JSON encoded
OAuth 2.0 authorization request parameters" to the definition of Request
Object in Section 2.1 (in addition to the note in the Introduction); my
apologies for not including that when I suggested the change to the
Introduction.
Please update the Content-Length in the example in Section 5.2.3.
Section 4
The client determines the algorithms used to sign and encrypt request
objects. This decision can be based on metadata the client
registered via dynamic client registration [RFC7591] using the
parameters "request_object_signing_alg",
"request_object_encryption_alg", "request_object_encryption_enc" as
defined in the the IANA "OAuth Dynamic Client Registration Metadata"
registry [IANA.OAuth.Parameters] established by [RFC7591].
I had to read this ("this decision can be based on [...]") a few times
to understand it. If I understand correctly, the idea is that the
client will register with the AS the keys it will use for constructing
the JAR, and in that way the AS has a binding from JAR-signing key to
the specific client and request. So it's true that the decision of what
key to use "can be based on" the metadata that the client registered, in
that deciding to use a different key than the registered one(s) is
likely to cause the AS to reject the request, but that's perhaps not the
main point. Would it work to instead just say that "The keys used to
sign and encrypt request objects (and thus, the algorithms that can be
used with those keys) can be registered via dynamic client registration
[...]"?
Section 5.2
The contents of the resource referenced by the URI MUST be a Request
Object, unless the URI was provided to the client by the
Authorization Server. The "request_uri" value MUST be either URN as
defined in RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of
RFC7230 [RFC7230] . The "request_uri" value MUST be reachable by the
Authorization Server.
I defer to my ART-area colleagues, but I'm not sure what it means for a
URN URI to be "reachable"; is this requirement intended to only apply to
the "https:" case?
Section 5.2.1
It is possible for the Request Object to include values that are to
be revealed only to the Authorization Server. As such, the
"request_uri" MUST have appropriate entropy for its lifetime. For
Is there a good reference for what the lifetime of such a request might
be? Perhaps I've been reading too much of GNAP, but my intuition is
that much of the time these requests will be single-use, and I don't
have as clear of a picture for when they might persist longer. There
are also potential security considerations for long-lived request
objects, in terms of making sure that there is a binding between the
client's intent to use a given request object for a given request, the
user's authorization, etc.
Section 5.2.3
(side note) I'd consider updating the timestamps in the example response
(and perhaps moving to Apache 2.4+ as well?).
Section 6.x
(nit) I suggest consistency in subsection headings, so, e.g., "JWE
Encrypted Request Object" and "JWS Signed Request Object".
Section 6.2
The Authorization Server MUST perform the signature validation of the
JSON Web Signature [RFC7515] signed request object. For this, the
"alg" Header Parameter in its JOSE Header MUST match the value of the
pre-registered algorithm. The signature MUST be validated against
the appropriate key for that "client_id" and algorithm.
This text suggests that pre-registration is mandatory, whereas up in
Section 4 the client's choice of algorithm was merely something that
"can be based on [metadata registered via dynamic registration]". I
know that dynamic registration is not the only kind of registration
possible, but we may want to wordsmith one (or both) location to improve
the consistency.
Section 6.3
I'd suggest reiterating here the requirement to verify "client_id"
consistency between Request Object and request parameters.
Section 10
I'd consider reiterating the security importance (i.e., what breaks if
you don't apply the check) of a few key compliance requirements and
which entity is responsible for
[OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-jwt-introspection-response-08: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/
--
DISCUSS:
--
Thank you for the updates in the -08; they address the bulk of the
substantive issues! I have a few points remaining on the -08 text but I
think there are more localized issues to resolve.
Can IANA please confirm that the new allocations in the -08 have
received appropriate Expert (e.g., media type) review? I see some
updates in the datatracker history relating to the -08 but nothing in
the email archives.
It looks like we need to register 'active' as a JWT claim?
I don't think the new semantics for "jti" in the introspection response
are compatible with the RFC 7519 definition. Specifically, we say that
"jti" will be tied to the input access token, but 7519 says that "jti"
has to change when the contents of the JWT change ("MUST be assigned in
a manner that ensures that there is a negligible probability that the
same value will be accidentally assigned to a different data object"),
and we admit at least the possibility of "active" and "iat" changing.
Section 5 says that:
If the access token is considered active, it MUST contain the claims
"iss" and "aud" in order to prevent misuse of the JWT as an ID or
access token (see Section 8.1).
But I don't think the predicate is correct -- misuse is still possible
by services that do not check the "active" claim's value. Shouldn't the
"iss"+"aud" requirements be unconditional?
--
COMMENT:
--
[New comments on the added text in the diff from -07 to -08.]
Section 3
To support encrypted token introspection response JWTs, the
authorization server MUST also be provided with the respective
resource server encryption keys and algorithms.
IIRC, based on some list discussion this text was going to be tweaked to
avoid implying that JWE is mandatory. (Unfortunately, this is the
thread that evolved into "client certs and TLS Terminating Reverse
Proxies", so it's hard to be sure whether I saw any other followups.)
The AS MUST restrict the use of client credentials by a RS to the
calls it requires, e.g. the AS MAY restrict such a client to call the
token introspection endpoint only. How the AS implements this
restriction is beyond the scope of this specification.
This should probably be clarified a bit more, in the context of "client
credentials tend to be used by privileged, fixed endpoints, and the
default may just be to allow them all access to all endpoints". Right
now it's not clear what's being restricted (and who "it" is that
requires calls)
Section 5
This specification registers the "application/token-
introspection+jwt" media type, which is used as value of the "typ"
header parameter of the JWT to indicate that the payload is a token
introspection response.
Do we also want to note that checking 'jti' is not mandatory and so this
does not necessarily provide full protection? (I guess Section 8.1
covers this in more detail.)
The value of the "aud" claims MUST identify the resource server
receiving the token introspection response.
We may want to dig into this a bit more: should there be any
relationship between this "aud" value and the "client_id" that an RS
might be using (as obtained from dynamic registration)?
Does this value need to be different from the audience that is used in
access tokens for which this RS is the audience? (Should it be the
same?) My instincts lean towards "different" but I would like broader
input.
exp The "exp" claim indicates when the access token passed in the
introspection request will expire.
On the face of it this seems divergent from RFC 7519's "the expiration
time on or after which the JWT MUST NOT be accepted for processing",
though upon further examination the distinction is not quite so large.
That is, it's in effect saying that the introspection response should
not be accepted for processing after the base token has expired, which
usually makes sense. There is a bit of a complication, though, in that
the "active" claim implies that we might still have RSes that plan to
use the introspection response after the "exp" date has passed, which
sounds a lot like a DISCUSS-level internal
[OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-jwt-bcp-07: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwt-bcp-07: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/ -- COMMENT: -- Thank you for addressing my Discuss (and Comment) points! ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-resource-indicators-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ -- COMMENT: -- Thank you for this easy-to-read-document -- reducing the risk of using bearer tokens seems worthwhile, since they are not going away very quickly. Abstract This seems to be a sentence fragment (maybe preface with "This document specifies"?). Section 1 When the authorization server is informed of the resource that will process the access token, it can restrict the intended audience of that token to the given resource such that the token cannot be used successfully at other resources. (This mechanism is only effective if the other resources are checking in some fashion, whether by direct inspection of a structured token or by a backchannel to the AS or otherwise, but I hope that checking 'aud' is standard practice by now!) Section 2.1 For authorization requests sent as a JWTs, such as when using JWT Secured Authorization Request [I-D.ietf-oauth-jwsreq], a single "resource" parameter value is represented as a JSON string while multiple values are represented as an array of strings. jwsreq includes an example with "aud" in the request, yet this new "resource" request parameter is also intended to influence the audience of the resulting token. I'm not sure whether we need to say anything specifically about this in the document, but I'd like to have a better understanding of how "aud" and "resource" would interact when both present in the reqeust. (This is presumably related to why the request parameter is called "resource" and not "aud" or "audience", but unfortunately I seem to have zoned out for that part of the WG discussion.) If the client omits the "resource" parameter when requesting authorization, the authorization server MAY process the request with no specific resource or by using a pre-defined default resource value. [...] Would/could this default value be global or on a per-scope basis or some other finer granularity than global? The authorization server might use this data to inform the user about the resources the client is going to access on her behalf, to meet policy decision (e.g. refuse the request due to unknown resources), and determine the set of resources that can be used in subsequent access token requests. nits: comma after "e.g.", and maybe s/meet policy decision/apply policy/ (or similar), and "to" before "determine" for parallelism. In Figure 1 we URL-encode the '.'s in "client.example.org" but not in "api.example.com" in the request URL; should we be consistent? (This seems to be recurring throughout the examples.) Section 2.2 needs to know. This further improves privacy as scope values give an indication of what services the resource owner uses and downscoping a token to only that which is needed for a particular service can limit the extent to which such information is revealed across different services. As specified in Section 5.1 of [RFC6749], the (nit?) I suggest to s/scope values give an indication of what services the resource owner uses and/a list of scope values is an indication that the resource owner uses the multiple various services listed;/ since I misparsed it the first time as-is. Section 3 An access token that is audience restricted to a protected resource that obtains that token legitimately cannot be used to access resources on behalf of the resource owner at other protected resources. The "resource" parameter enables a client to indicate the nit: This sentence has a pretty strange construction. I think the intent is to say that that a token, legitimately presented to a resource, cannot then be taken by that resource server and illegitimately present it somewhere else for access to other resources. But with the current wording we seem to be missing part of the part where some entity obtains the token with intent for illegitimate access. Some servers may host user content or be multi-tenant. In order to avoid attacks that might confuse a client into sending an access token to a resource that is user controlled or is owned by a different tenant, it is important to use a specific resource URI including a path
[OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-07: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwt-introspection-response-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ -- DISCUSS: -- Per the ongoing discussion on the WG list, it's unclear that we can retain the behaviors we describe and still comply with the requirements of RFC 7519 requirements for being a JWT (e.g., regarding "jti", "iat", etc.). That is, in the present formulation, there are two "token"s involved -- the input that is being introspected, and the "token" that is the introspection response. We are claiming that certain fields are describing the input token, when they are defined to be statements about the current (response) token. Relaxing our statements to say that we merely use JWS as opposed to JWT may be a workaround, though I have thought about it hard enough to have an opinion on whether it is the best workaround. I also think we need more clarity about the use of dynamic client registration by a resource server as outlined in Section 4 (where it's mentioned as "with a resource server posing as the client", without reference to RFC 7591. As far as I can tell this document/section is introducing this use of dynamic client registration by an RS for the first time, so we cannot easily just refer to some other document. Specifically, are there any fields that MUST NOT be supplied? Is a human-readable client_name useful? How does the supplied client_uri need to relate to any existing AS representation of a resource in audience, scope, etc. (e.g., for the "resource" request parameter from draft-ietf-oauth-resource-indicators)? Is this usage considered to be a "new use of JWTs"? If so, it seems that we should follow the recommendation of draft-ietf-oauth-jwt-bcp and use explicit typing. I think there are some missing links in the document between a RS registring client policy and the resulting AS enforcement of encryption of introspection reponses. I think the intent is roughly that the policy will be applied based on the audience of the token being presented for introspection (as opposed to the identity of the RS-as-client making the introspection request), but we don't seem to explicitly say that. Also, we'd need to say something about the interaction of multiple RSs' policy when a given token has multiple valid audiences. There is a very brief discussion in Section 6.5, but it seems to be more of a description of what is possible than mandating particular forms of enforcement. I think we should discuss whether we want some statement from the OpenID Foundation or related bodies before we register claims that point to their documents with the IESG listed as change controller. -- COMMENT: -- idnits notes that RFC 5646 is mentioned but not present in the references section. Section 1 We probably need to move the 7519 reference up here to where JWT is first used. OAuth 2.0 Token Introspection [RFC7662] specifies a method for a protected resource to query an OAuth 2.0 authorization server to determine the state of an access token and obtain data associated with the access token. This allows deployments to implement identifier-based access tokens in an interoperable way. Does "identifier-based access tokens" mean "tokens that are opaque keys to a (central) database lookup" or "access tokens that convey user identity information" (or something else)? We may want to tweak the wording. Section 3 Can we double-check the base64 form of the response in this example? I am seeing output that backslash-escapes the '/' characters in URLs, which I did not think was needed in this context. I also see an "extension_field" claim in the base64 but not the decoded form of the example, and "given_name"/"family_name"/"birthdate" in the decoded example vs. "username" in the base64 version. Note: If the resource server policy requires a signed and encrypted response and the authorization server receives an unauthenticated request containing an Accept header with content type other than "application/jwt", it MUST refuse to serve the request and return an HTTP status code 400. This is done to prevent downgrading attacks to obtain token data intended for release to legitimate recipients only (see Section 6.2). I'd suggest a
[OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-mtls-17: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-mtls-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ -- COMMENT: -- Thank you for addressing my Discuss (and Comment!) points! ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-mtls-16: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-mtls-16: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/
--
DISCUSS:
--
(1) I think that we need some text that covers how the resource server
will know to use mtls (and thus, to send a CertificateRequest to the
client during the TLS handshake). The authorization server and client
can indicate their capabilities/preference via the RFC 8414 and RFC 7591
discovery and registration procedures, but I didn't see any discussion
of how an AS might know a RS's capabilities, or how an RS might develop
expectations of the capabilities of the clients accessing it. A naive
conclusion might be that any given RS (hostname+port) would have to
either always or never use mtls, given the misordering between TLS
handshake completion and delivery of TLS application data (i.e.,
including the oauth token), though there may be refinements available in
the form of the unpopular TLS 1.2 renegotiation or TLS 1.3
post-handshake authentication (or exported authenticators). Doing
either of those in an environment with TLS Termination per Section 6.5
may entail additional complications.
(We may also want some additional text discussing error handling for the
client/AS interaction, e.g., if a request shows up from a client-id that
should be using mtls but did not provide a certificate in the TLS
handshake, but that is only debatably something that rises to
Discuss-level; or if a client that advertised an intent to use MTLS used
the regular token endpoint and not the mtls endpoint alias (if they
differ).)
(2) I can't validate the examples in Appendix A.
Specifically, my reading of the text would put the "x5t#S256" value as
needing 86 characters, but only 43 are provided. The ones there also do
not seem to be a prefix of the result that I get from taking the PEM
certificate contents and running them through the pipeline:
base64 -di | sha256sum |awk '{print $1}'|tr -d '\n'|base64
(Noting, of course, that 'base64' will be producing the non-URL-safe
variant, but expecting it to remain "pretty close".)
I also had some trouble comparing the "y" coordinate from the JWK to the
certificate contents, but that may just be user error.
--
COMMENT:
--
Section 1
nit: in Figure 1, the (C) label is applied to both an arrow and a box
(the other two boxes are not labelled).
(C) The protected resource validates the access token in order to
authorize the request. In some cases, such as when the token is
self-contained and cryptographically secured, the validation can
be done locally by the protected resource. While other cases
require that the protected resource call out to the
authorization server to determine the state of the token and
obtain meta-information about it.
nit: "While" is a conjunction but this last sentence only has one
clause.
Layering on the abstract flow above, this document standardizes
enhanced security options for OAuth 2.0 utilizing client certificate
based mutual TLS. Section 2 provides options for authenticating the
nit: "client-certificate-based" is hyphenated.
request in step (A). While step (C) is supported with semantics to
express the binding of the token to the client certificate for both
local and remote processing in Section 3.1 and Section 3.2
respectively. This ensures that, as described in Section 3,
nit: same thing about "while".
protected resource access in step (B) is only possible by the
legitimate client bearing the access token and holding the private
key corresponding to the certificate.
nit: I guess it is only protected resource access "using this tokwn"
that is only possible as specified.
Section 1.2
We probably want to say something like "in addition to the normal TLS
server authentication with a certificate" -- we need both for it to
properly be "mutual" :)
Section 2.1
The PKI (public key infrastructure) method of mutual TLS OAuth client
authentication adheres to the way in which X.509 certificates are
traditionally used for authentication. It relies on a validated
certificate chain [RFC5280] and a single subject distinguished name
(DN) or a single subject alternative name (SAN) to authenticate the
client. Only one subject name value of
[OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-token-exchange-17: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-token-exchange-17: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ -- COMMENT: -- I'm balloting Yes; this document is solid and well-written. I do have a few additional (largely editorial) suggestions and a question or two, though. Section 2.1 The client makes a token exchange request to the token endpoint with an extension grant type using the HTTP "POST" method and including the following parameters using the "application/x-www-form- urlencoded" format with a character encoding of UTF-8 in the HTTP request entity-body as described in Appendix B of RFC6749 [RFC6749]. This is a really long sentence. I see how it got that way, and the RFC Editor staff will probably have some thoughts on how to reword it, but if you happen to have thoughts as well, feel free to have at it. Section 2.2.1 expires_in RECOMMENDED. The validity lifetime, in seconds, of the token issued by the authorization server. Oftentimes the client will not have the inclination or capability to inspect the content of the token and this parameter provides a consistent and token type agnostic indication of how long the token can be expected to be valid. For example, the value 1800 denotes that the token will nit: hyphenate "token-type-agnostic". Section 4.4 Refresh my memory: did we already have a discussion about may_act as an object vs. an array of objects? Section 5 I'd consider also mentioning/linking the OAuth 2.0 security considerations -- the fact that the STS is colocated with the token endpoint takes care of ensuring a lot of its security properties. Section 7 It's common (but not required, since it will not be relevant upon publication as an RFC) to note that the indicated values are reflected in early allocations from the indicated IANA registries. In this case I'd say "don't bother"... Appendix B Uh-oh, now we are up to five security ADs that have been around for this document... ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwsreq-19: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ -- DISCUSS: -- My apologies; my previous position was incomplete. Updated to note namespacing issues, and one minor terminology nit about "DNS-ID". There seem to be some pretty serious namespacing issues that are not discussed at all in this document. Specifically, using JWT as a container for OAuth 2.0 authorization request parameters (including extension parameters) introduces the usage of many new names (of JSON name/value pairs) into the JWT claims namespace. Furthermore, the addition is not bounded, as any new OAuth extension parameters are implicitly permitted to be used as well! The IANA Considerations make no mention of the collapsed namespace for JWT claims and OAuth 2.0 (authorization request) parameters, leaving substantial potential for collisions in the future. Relatedly, using "application/jwt" as the Content-type of the HTTP response from dereferencing the request_uri with no explicit indication of the type/profile of JWT used (whether in the content type or in the JWT claims themselves) gives some risk of misinterpretation of the content. Consider, for example, when that request_uri is dereferenced not by the authorization server in the process of fulfilling an authorization request, but instead by some other service that expects a different type of JWT. This second point is a "discuss discuss" -- it's an important question and I'd like to talk about it, but it's not clear that any change to the document will be needed. The introduction notes as an advantage of JWT that: (d) (collection minimization) The request can be signed by a third party attesting that the authorization request is compliant with a certain policy. For example, a request can be pre-examined by a third party that all the personal data requested is strictly necessary to perform the process that the end-user asked for, and statically signed by that third party. The authorization server then examines the signature and shows the conformance status to the end-user, who would have some assurance as to the legitimacy of the request when authorizing it. In some cases, it may even be desirable to skip the authorization dialogue under such circumstances. I'm pretty uncomfortable about suggesting that the authorization dialogue can/should be skipped; do we need to keep this example? -- COMMENT: -- Section 1 While it is easy to implement, the encoding in the URI does not allow application layer security with confidentiality and integrity protection to be used. While TLS is used to offer communication nit: this wording is a little hard to read; it might be easier to reorder to "does not allow application layer security to be used to provide confidentiality and integrity protection". The use of application layer security allows requests to be prepared by a third party so that a client application cannot request more permissions than previously agreed. This offers an additional degree of privacy protection. (side note) what would an example of such a third party be. (We already have the resource owner, the client, and the authorization server ... maybe it's a fourth party?) Furthermore, the request by reference allows the reduction of over- the-wire overhead. We only barely mentioned by-reference at this point (one line in the Abstract), so I'd suggest "passing the request by reference". (4) its development status that it is an RFC and so is its associated signing and encryption methods as [RFC7515] and [RFC7516] nit: I'd suggest "its development status as a Proposed Standard, along with the associated signing and encryption methods [RFC7515] [RFC7516]." (c) (confidentiality protection) The request can be encrypted so that end-to-end confidentiality can be provided even if the TLS connection is terminated at one point or another. nit: TLS is always terminated at or before the user-agent, though. So maybe the user agent needs to get called out here as well (there could of course be TLS termination earlier than the user-agent in some cases, too). 2.
[OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwsreq-19: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ -- DISCUSS: -- This is a "discuss discuss" -- it's an important question and I'd like to talk about it, but it's not clear that any change to the document will be needed. Once this (and some of the more substantive items in the Comment section) is resolved, I'd be happy to ballot Yes. The introduction notes as an advantage of JWT that: (d) (collection minimization) The request can be signed by a third party attesting that the authorization request is compliant with a certain policy. For example, a request can be pre-examined by a third party that all the personal data requested is strictly necessary to perform the process that the end-user asked for, and statically signed by that third party. The authorization server then examines the signature and shows the conformance status to the end-user, who would have some assurance as to the legitimacy of the request when authorizing it. In some cases, it may even be desirable to skip the authorization dialogue under such circumstances. I'm pretty uncomfortable about suggesting that the authorization dialogue can/should be skipped; do we need to keep this example? Maybe just talking about what an expected use case could be would help alleviate my unease. -- COMMENT: -- Section 1 While it is easy to implement, the encoding in the URI does not allow application layer security with confidentiality and integrity protection to be used. While TLS is used to offer communication nit: this wording is a little hard to read; it might be easier to reorder to "does not allow application layer security to be used to provide confidentiality and integrity protection". The use of application layer security allows requests to be prepared by a third party so that a client application cannot request more permissions than previously agreed. This offers an additional degree of privacy protection. (side note) what would an example of such a third party be. (We already have the resource owner, the client, and the authorization server ... maybe it's a fourth party?) Furthermore, the request by reference allows the reduction of over- the-wire overhead. We only barely mentioned by-reference at this point (one line in the Abstract), so I'd suggest "passing the request by reference". (4) its development status that it is an RFC and so is its associated signing and encryption methods as [RFC7515] and [RFC7516] nit: I'd suggest "its development status as a Proposed Standard, along with the associated signing and encryption methods [RFC7515] [RFC7516]." (c) (confidentiality protection) The request can be encrypted so that end-to-end confidentiality can be provided even if the TLS connection is terminated at one point or another. nit: TLS is always terminated at or before the user-agent, though. So maybe the user agent needs to get called out here as well (there could of course be TLS termination earlier than the user-agent in some cases, too). 2. When the client does not want to do the crypto. The Authorization Server may provide an endpoint to accept the Authorization Request through direct communication with the Client so that the Client is authenticated and the channel is TLS protected. How can you "not want to do [the] crypto" but still be doing TLS (with crypto)? Perhaps we're looking for "not want to pay the additional overhead of JWS/JWE cryptography on top of TLS"? Section 1.1 RFC 8174 has updated BCP 14 boilerplate text to use. Section 3 nit: should this section be 2.3 to get wrapped into "terminology"? It might also be worth putting references in for the terms, though they are largely common knowledge at this point. Section 4 A Request Object (Section 2.1) is used to provide authorization request parameters for an OAuth 2.0 authorization request. It MUST contains all the OAuth 2.0 [RFC6749] authorization request parameters including extension parameters. The parameters are represented as nit: "all the parameters" kind of sounds like "all that are defined".
[OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-bcp-06: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-jwt-bcp-06: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/
--
DISCUSS:
--
Thank you for assembling this document; it will be very valuable to the
community. I intend to ballot Yes once the following items are
resolved:
Section 2.6 notes:
Previous versions of the JSON format such as the obsoleted [RFC7159]
allowed several different character encodings: UTF-8, UTF-16 and UTF-
32. This is not the case anymore, with the latest standard [RFC8259]
only allowing UTF-8. [...]
The actual situation is a bit more subtle than this text makes it seem;
interoperable JSON can only use non-UTF-8 with explicit mutual
prearrangement in a closed ecosystem. So, while this statement is true
for Internet JWT usage, it may not be true for *all* JWT usage.
(I do see that in Section 3.7 of this document we do mandate UTF-8 for
JWT, which makes things unambiguous, even if this text here is not
correct.)
Section 3.2 notes:
JWT libraries SHOULD NOT generate JWTs using "none" unless explicitly
requested to do by the caller.
I couldn't find anywhere where we have matching guidance about "SHOULD
NOT consume JWTs using 'none' unless explicitly requested"; this seems
important enough to get called out explicitly.
--
COMMENT:
--
I also have some non-Discuss-level substantive comments in the
section-by-section notes,
in addition to the usual editorial nits.
Section 1
and/or encrypted. The JWT specification has seen rapid adoption
because it encapsulates security-relevant information in one, easy to
protect location, and because it is easy to implement using widely-
nit: "one easy-to-protect location".
Section 2.2
I'd consider rewording the text here to make it more poignant; perhaps:
In addition, some applications use a keyed MAC algorithm such as
"HS256" to sign tokens, but supply a weak symmetric key with
insufficient entropy (such as a human memorable password). Such keys
are vulnerable to offline brute-force or dictionary attacks once an
attacker possesses such a token.
Section 2.4
I'd suggest noting that the compression attacks are particularly
powerful when there is attacker-controlled data in the same compression
space as secret data.
Section 3.2
Therefore, applications MUST only allow the use of cryptographically
current algorithms that meet the security requirements of the
application. This set will vary over time as new algorithms are
introduced and existing algorithms are deprecated due to discovered
cryptographic weaknesses. Applications MUST therefore be designed to
enable cryptographic agility.
This seems to have high overlap with BCP 201; a reference is probably in
order.
Section 3.4
Some cryptographic operations, such as Elliptic Curve Diffie-Hellman
key agreement ("ECDH-ES") take inputs that may contain invalid
values, such as points not on the specified elliptic curve or other
invalid points (see e.g. [Valenta], Sec. 7.1). Either the JWS/JWE
library itself must validate these inputs before using them or it
must use underlying cryptographic libraries that do so (or both!).
side note: A phrasing like "JWS/JWE libraries MUST ensure that such
input validation occurs" would leave the same wiggle room for the
validation to occur at the underlying crypto layer, while leaving it
crystal clear what entity is responsible for ensuring that the checks
occur". But since I don't expect a change of this nature to actually
cause different behavior by implementors, I'm not very tied to it.
Section 3.8
When we say "[o]ther applications may use different means of binding
keys to issuers", is there any value in noting that certification by a
trusted authority is a common way to perform this binding (in some
contexts)?
Section 3.9
If the same issuer can issue JWTs that are intended for use by more
than one relying party or application, the JWT MUST contain an "aud"
(audience) claim that can be used to determine whether the JWT is
being used by an intended party or was substituted by an attacker at
an unintended party. Furthermore, the relying party or application
MUST validate the audience value and if the audience value is not
present or not associated with the
