IETF Last Call Review of draft-ietf-oauth-identity-chaining-11
review-ietf-oauth-identity-chaining-11-genart-lc-eggert-2026-05-04-00

# genart-lc review of draft-ietf-oauth-identity-chaining-11

CC @larseggert

I am the assigned Gen-ART reviewer for this draft. The
General Area Review Team (Gen-ART) reviews all IETF
documents being processed by the IESG for the IETF
Chair. Please treat these comments just like any other
last call comments. For more information, please see the
[FAQ](https://wiki.ietf.org/group/gen/GenArtFAQ).

Please check all instances of where you use a 2119 "MAY" - I think you're not
using it correctly in all cases. See below for details.

## Comments

### Section 2.3.1, paragraph 4
```
     resource
        REQUIRED if audience is not set.  URI of authorization server for
        trust domain B.

     audience
        REQUIRED if resource is not set.  Well known/logical name of
        authorization server for trust domain B.
```
So is this supposed to express "resource XOR audience"? Or that one of them
MUST be set but the other need not (but MAY or SHOULD)?

### Section 2.3.2, paragraph 2
```
     *  The authorization server in trust domain A MAY add, remove or
        change claims.  See Claims transcription (Section 2.5).
```
This might be better expressed that the server in domain B MUST handle the
server in domain A doing this. Otherwise, it's not clear that this is a
requirement on domain B.

### Section 2.3.3, paragraph 3
```
     *  The "aud" claim included in the returned JWT authorization grant
        MAY identify multiple authorization servers, provided that trust
        relationships exist with them.  It is RECOMMENDED that the "aud"
```
This MAY is again probably a MUST on the receiver needing to handle this.

### Section 2.4.1, paragraph 4
```
     The client in trust domain A MAY indicate the protected resource it
     is trying to access through the scope parameter or the resource
     parameter defined in [RFC8707].
```
Again a MAY on the sender that is in reality a MUST on the receiver.

### Section 2.4.2, paragraph 3
```
     *  The authorization server in trust domain B SHOULD deny the request
        if it is not able to identify the subject.
```
When would it be OK to not deny the request?

### Section 2.5, paragraph 2
```
     Authorization servers MAY transcribe claims when either producing JWT
     authorization grants in the token exchange flow or access tokens in
     the assertion flow.  Transcription of claims may be required for the
     following reasons:
```
Same as for the other MAYs. Please review all such usage, I will not comment on
further instances.

### Too many authors

The document has six authors, which exceeds the recommended author limit. Has
the sponsoring AD agreed that this is appropriate?

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Section 2.1, paragraph 3
```
              Figure 1: Identity and Authorization Chaining Flow
```
Nit: You might want to pass this and other ASCII art through
https://github.com/martinthomson/aasvg to get an SVG for inclusion in your
Markdown.

### Grammar/style

#### Section 4.2, paragraph 2
```
ance across domains in the context of a assertion grant. It does not relate
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 7.1, paragraph 6
```
ining credentials it also allows fine grained access control at the resource
                                 ^^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

#### Section 7.1, paragraph 10
```
ty Provider (IdP) does not have to sign-in to multiple SaaS applications if t
                                   ^^^^^^^
```
When "sign in" is used as a verb, it does not need to be hyphenated.

#### "B.2.", paragraph 8
```
" claim to generate a DPoP proof or setup a MTLS session when presenting the
                                    ^^^^^
```
The verb "set up" is spelled as two words. The noun "setup" is spelled as one.

#### "B.2.", paragraph 8
```
he access token to a resource server in in trust domain B. Appendix C. Acknow
                                     ^^^^^
```
Possible typo: you repeated a word.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF]. You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool