[OAUTH-WG] Re: Shepherd Review - OAuth Identity and Authorization Chaining Across Domains

[Brian Campbell <[e-mail]>]

Thanks Rifaat and apologies on behalf of the editorial team for being
somewhat slow to get to this. Attempts at responding to individual items
are inline below.  And this PR
https://github.com/oauth-wg/oauth-identity-chaining/pull/176 is collecting
the resultant changes, which I hope to go over with folks tomorrow er...
today in like an hour in an informal semi-recurring call with some of the
editors and interested parties.


On Thu, Jan 29, 2026 at 6:36 AM Rifaat Shekh-Yusef <[e-mail]>
wrote:

> All,
>
> As the shepherd for this document, I have reviewed the latest version of
> the draft
> https://www.ietf.org/archive/id/draft-ietf-oauth-identity-chaining-06.html
>
> I have the following comments/questions:
>
> Section 2.1
>
> It would be great if a sentence or two are added to explain why the
> initial interaction in domain A is limited to token exchange.
>

The idea makes sense in my head but writing the words proved more
difficult. This is what I managed:
https://github.com/oauth-wg/oauth-identity-chaining/pull/176/changes/45d233f4cc8b07c7d3c5a22dcf3e683688c70bb7
as
part of the PR


>
>
> Section 2.1, bullet (C)
>
> where domain B's authorization server trusts the public key(s) of domain A
>> to sign JWT authorization grants
>
>
> I think I understand what this sentence is trying to say, but I think it
> needs to be reworded, because you cannot use public keys to sign a JWT.
>

Yep:
https://github.com/oauth-wg/oauth-identity-chaining/pull/176/changes/3c9f90442aacf5b8fba794d7b455ff22191582df




>
>
> Section 2.3.2, first bullet
>
> It would be great if you can add a reference to a document that explicitly
> defines which error code would be used to deny the request.
>


Yep,
https://github.com/oauth-wg/oauth-identity-chaining/pull/176/changes/09b2edd2794416573dea91ea6d02e00a480623f7



>
>
> Section 2.4.1, 3rd bullet
>
> You might want to add some text to explain ‘scope’
>

That's embarrassing. I took a little different approach to fixing it
though:
https://github.com/oauth-wg/oauth-identity-chaining/pull/176/changes/463c0bb9a892fc3f0703abdd12071e0e7c8f9aa5



>
>
> Section 2.4.2, second bullet
>
> It would be great if you can add a reference to a document that explicitly
> defines which error code would be used to deny the request.
>

Yup,
https://github.com/oauth-wg/oauth-identity-chaining/pull/176/changes/3eff55a90f8daf5138f65dba46b149f93b9083b8


>
>
> Section 2.5, last bullet
>
> The populated claims SHOULD be namespaced or validated to prevent the
>> injection of invalid claims.
>
>
> Can you elaborate on this sentence?
>

Honestly, I don't know what that means nor am I able to discern what might
have been intended. So going with
https://github.com/oauth-wg/oauth-identity-chaining/pull/176/changes/7df2b2f5ceeda1cb713dbfb1efa63cafbe057951
on this


>
>
> Section 3
>
> Authorization servers MAY choose not to advertise some supported requested
>> token types…
>
>
> What would be the reasons for doing this?
>

Information disclosure concerns maybe? Going with that:
https://github.com/oauth-wg/oauth-identity-chaining/pull/176/changes/4f00cea01e18b7b9262f4fe82a8ab1b563f81787


>
>
> Section 5.1 and 5..2
>
> Why is the use of SHOULD instead of MUST?
>

attempt to qaulify things there with
https://github.com/oauth-wg/oauth-identity-chaining/pull/176/changes/d0f8b70e335d76172cfd22cf7aa4ba2f8102f798
and
https://github.com/oauth-wg/oauth-identity-chaining/pull/176/changes/ace14363b0d9e52c9e9a619a6ce00487aedaf3f7


>
>
> Section 5.3
>
> The authorization server in trust domain A SHOULD perform client
>> authentication
>
>
> You might want to elaborate on why this is a SHOULD and not a MUST, to
> make sure the implementer understands in which cases this is possible and
> which is not.
>

yep, tried to do that in
https://github.com/oauth-wg/oauth-identity-chaining/pull/176/changes/3269e141bda313f3a03777c50ded1316f9f06bc7




>
> Section 5.4
>
> The authorization server in trust domain B SHOULD NOT issue refresh tokens
>> to the client within the scope of this specification.
>
>
> Are there use cases where the AS can issue refresh tokens? If yes, then
> maybe provide an example, if no, then maybe this should be a MUST NOT?
>

I think I'd prefer a MUST NOT here but back in the development of RFCs
7521/7522/7523 there was enough resistance to that prohibition that it is
kind of discouraged but not disallowed. Going further here seemed like too
much. But maybe? Anyway, I tried to explain it a bit with
https://github.com/oauth-wg/oauth-identity-chaining/pull/176/changes/7e57b8115d0f75c26dc4a63b89dd7a7fc7752b4a

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._