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 <[email protected]> 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._
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
