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

[Brian Campbell <[e-mail]>]

And -07 is out with those updates
https://mailarchive.ietf.org/arch/msg/oauth/ru9IXKjK79ng3MbZ1vnKYVVF_CE/

On Fri, Feb 6, 2026 at 7:02 AM Brian Campbell <[e-mail]>
wrote:

> 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._