Summary: Has 3 DISCUSSes. Needs one more YES or NO OBJECTION position to pass.
Section 6: The requirements around confidentiality here are weaker than in both RFC 7519 Sec. 12 and RFC 6749 Sec. 10.8. Why?
Section 3: If I understand this correctly: "The distinction between an access token and a JWT is subtle." I think it would be clearer if it said: "The distinction between an access token type and a JWT token type is subtle." Section 4.1: What is the value of maintaining the whole delegation chain rather than expressing just the most recent delegation? Doesn't it potentially expose information about past exchanges unnecessarily?
It looks like allocations in the OAuth URIs registry are merely "Specification Required", so we should not have the expectation of WG exclusivity and thus are squatting on unallocated values here. Process-wise, that's not great and the IESG shouldn't approve a document that is squatting on codepoints. why do we allow both client authentication (i.e., using an actor token) and a distinct actor_token request parameter? Is it supposed to be the case that the actor_token parameter is only supplied for delegation flows? If so, that needs to be made explicit in the document. Are the privacy considerations (e.g., risk of a tailed per-request error_uri) relating to the use of error_uri discussed in some other document that we can refer to from this document's security considerations? (I say a bit more about this in my COMMENT.) Section 2.1 has: audience OPTIONAL. The logical name of the target service where the client intends to use the requested security token. This serves a purpose similar to the "resource" parameter, but with the client providing a logical name rather than a location. Interpretation of the name requires that the value be something that both the client and the authorization server understand. An OAuth client identifier, a SAML entity identifier [OASIS.saml-core-2.0-os], an OpenID Connect Issuer Identifier [OpenID.Core], or a URI are examples of things that might be used as "audience" parameter values. [...] How does the STS know what type of identifier it is supposed to interpret the provided audience value as?
The document could perhaps benefit from greater clarity as to whether "security token"s refer to inputs, outputs, or both, of the token endpoint (for the interactions defined in this specification). Section 1 The OAuth 2.0 Authorization Framework [RFC6749] and OAuth 2.0 Bearer Tokens [RFC6750] have emerged as popular standards for authorizing third- party applications access to HTTP and RESTful resources. [...] nit: possessive "applications'" Section 1.1 This section really jumps in quickly with no lead-in to why we would care or transition from the introduction. I suggest: One common use case for an STS (as alluded to in the previous section) is to allow a resource server A to make calls to a backend service C on behalf of the requesting user B. Depending on the local site policy and authorization infrastructure, it may be desireable for A to use its own credentials to access C along with an annotation of some form that A is acting on behalf of B ("delegation"), or for A to be granted a limited access credential to C but that continues to identify B as the authorized entity ("imperesonation"). Delegation and impersonation can be useful concepts in other scenarios involving multiple participants as well. Section 2.1 For example, [RFC7523] defines client authentication using JSON Web Tokens (JWTs) [JWT]. Please clarify that these are still bearer tokens. The supported methods of client authentication and whether or not to allow unauthenticated or unidentified clients are deployment decisions that are at the discretion of the authorization server. It seems appropriate to note that omitting client authentication allows for a compromised token to be leveraged via an STS into other tokens by anyone possessing the compromised token, and thus that client authentication allows for additional authorization checks as to which entities are permitted to impersonate or receive delegations from other entities. The client makes a token exchange request to the token endpoint with an extension grant type by 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: Is there more to say than "just use UTF-8"; any normalization or canonicalization issues to consider? subject_token REQUIRED. A security token that represents the identity of the party on behalf of whom the request is being made. Typically, the subject of this token will be the subject of the security token issued in response to this request. nit: I think there's a subtle grammar mismatch here, where we start off by talking about a/the request and end up with "this request". In processing the request, the authorization sever MUST validate the subject token as appropriate for the indicated token type and, if the actor token is present, also validate it according to its token type. I misread this the first time around; I'd suggest something like "perform the appropriate validation procedures for the indicated token type" (as opposed to just verifying that the presented token is a syntactically valid instance of the claimed type). In the absence of one-time-use or other semantics specific to the token type, the act of performing a token exchange has no impact on the validity of the subject token or actor token. Furthermore, the validity of the subject token or actor token have no impact on the validity of the issued token after the exchange has occurred. Do we really want this strong of a statement? I suspect that in many environments propagating, e.g., expiration time to the exchanged credential may be desired. Section 2.2.1 token_type [...] contents of the token itself. Note that the meaning of this parameter is different from the meaning of the "issued_token_type" parameter, which declares the representation of the issued security token; the term "token type" is typically used with this meaning, as it is in all "*_token_type" parameters in this specification. [...] Please disambiguate what "typically used with this meaning" means. Perhaps it would be even more clear to change this field's name to "token_access_token_type" to match the name of the registry? Section 2.3 The following example demonstrates a hypothetical token exchange in which an OAuth resource server assumes the role of the client during token exchange in order to trade an access token that it received in a protected resource request for a token that it will use to call to a backend service (extra line breaks and indentation in the examples are for display purposes only). We could maybe add some commas or parentheses to help the reader group the various clauses properly. E.g., it is "(trade an access token (that it received in a protected resource request)) for a token...", not "trace an access token that it received (in a protected resource request for a token)", where parentheses indicate logical grouping. grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange &resource=https%3A%2F%2Fbackend.example.com%2Fapi%20 &subject_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC &subject_token_type= urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token Figure 2: Token Exchange Request Is there really supposed to be a %20 in the resource query parameter's value? The token octets in Figures 3 and 4 do not match up, despite the prose indicating that they are the same token. Section 3 Would it be appropriate to note (here or elsewhere) that for non-JWT token formats that are a binary format, the URI used for conveying them needs to be associated with the semantics of base64 (or otherwise) encoding them for usage with OAuth? Token Exchange can work with both tokens issued by other parties and tokens from the given authorization server. [...] Does "work with" mean "accept as input" or "produce as output" or both? For input, as both subject_token and actor_token? The following token type identifiers are defined by this specification. Other URIs MAY be used to indicate other token types. I'd also link to the registry here. Why is the text about "urn:ietf:params:oauth:token-type:jwt" formatted differently than the other URIs listed? Section 4.1 Do we want to consider a more self-describing subject identifier scheme, akin to https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers ? The example in Figure 5 appears to be using the "implicit issuer" behavior wherein the "iss" of the actor's "sub" is assumed to be the same value as in the containing structure. I'm not a fan of this type of behavior in general, but if it's going to be used, you need to document the possibility in some fashion. I might also consider some language about how "the nested "act" claims serve as a history trail that connects the initial request and subject through the various delegation steps undertaken before reaching the current actor. In this sense, the current actor is considered to include the entire authorization/delegation history, leading naturally to the nested structure described here". (But see also the other ballot comment about this potentially leaking information to unauthorized parties; it seems a more careful adjustment of the text is in order here.) Section 4.2 Is this really the first time we're defining "scope" as a JWT claim? I would have thought that would be defined long ago... Section 4.4 Just to double-check: this is "things that can act as me" (where "me" is the subject of the token containing this field), right? The parenthetical "May Act For" doesn't really help me decide whether this claim represents the source or target of a permitted delegation, so maybe "Allowed Impersonators" or similar would be more clear. Even "act as" or "act on behalf of" instead of "act for" would help me, I think. [This would have trickle-down effects to later parts of the document as well, e.g., the IANA Considerations.] (Not that I claim to be a representative population, of course!) It would probably also help greatly to note that when a subject_token is presented to the token endpoint in a token exchange request, the "may_act" claim in the subject token can be used by the authorization service to determine whether the client (or party identified in the actor_token) is authorized to engage in the requested delegation [or impersonation]. Section 6 Let me say a bit more here about my perception of the potential privacy considerations involved in the use of an error_uri (so we can figure out if they are already discussed in a relevant document that we can cite; JWT itself doesn't seem to cover this topic). By sending an error_uri instead of an error string, the server is in effect causing the client to make an outbound request to a URL of the server's choosing. If there is a proxy between the client and server, this could result in the server (and/or a party controlled by the server) learning additional information about the client's identity/location. A malicious server could also attempt to construct a URI that, when retrieved by the client, performs some unwanted side effect. Defenses against this latter scenario are pretty well known in the web comunity, but we may want to be sure that the need for them is mentioned in a discoverable place. Appendix A.1.1 In the following token exchange request, a client is requesting a token with impersonation semantics. [...] What part of the request indicates that impersonation semantics are requested? Is the use of the "jwt" subject_token_type appropriate, given the previous discussion about id_token/access_token being generally preferred (as conveying more meaning)?
Thanks to everyone who worked on this document. I have a blocking issue that should be easy to resolve, and a handful of more minor issues. §2.1: > The client makes a token exchange request to the token endpoint with > an extension grant type by including the following parameters using > the "application/x-www-form-urlencoded" format This document needs a normative citation for this media type. My suggestion would be to cite REC-html5-20141028 section 184.108.40.206, as this appears to be the most recent stable description of how to encode this media type. I'd love to hear rationale behind other citations being more appropriate, since I'm not entirely happy with the one I suggest above (given that it's been superseded by HTML 5.2); but every other plausible citation I can find is even less palatable (with HTML 5.2 itself having the drawback of not actually defining how to encode the media type, instead pointing to an unstable, unversioned document).
Abstract: > This specification defines a protocol for an HTTP- and JSON- based Nit: "...JSON-based..." --------------------------------------------------------------------------- §1.1: > impersonates principal B, then in so far as any entity receiving such Nit: "insofar" --------------------------------------------------------------------------- §2.1: > The client makes a token exchange request to the token endpoint with > an extension grant type by 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: I think there's an implication here that POST is used, but that probably needs to be made explicit. --------------------------------------------------------------------------- §2.2.1: > response using the "application/json" media type, as specified by > [RFC7159], and an HTTP 200 status code. The parameters are RFC 7159 has been replaced by RFC 8259. --------------------------------------------------------------------------- §3: > urn:ietf:params:oauth:token-type:refresh_token > Indicates that the token is an OAuth 2.0 refreshe token issued by nit: "refresh"