As far as I can tell, the secdir review was due over six weeks ago. IESG balloting has already occurred and the draft is in the RFC Editor Queue.
I am honestly struggling to understand what actual action is expected at this point or why a directorate review would be even be submitted at this stage. FWIW, there is some discussion of pseudonymous or anonymous usage in the underlying RFC's such as https://datatracker.ietf.org/doc/html/rfc7523#section-3 and https://datatracker.ietf.org/doc/html/rfc7521#section-6.3.1 On Wed, Jun 24, 2026 at 2:49 PM Phillip Hallam-Baker via Datatracker < [email protected]> wrote: > Document: draft-ietf-oauth-identity-chaining > Title: OAuth Identity and Authorization Chaining Across Domains > Reviewer: Phillip Hallam-Baker > Review result: Has Issues > > This draft describes a mechanism for chaining OAUTH authorizations so that > an > authorization server in trust domain A can provide a client with a token > that > grants access to a resource in trust domain B. > > While the draft mentions 'claims transcription' and the case where Jon Doe > has > a different user identifier in another domain, it does not address the > case in > which this mechanism is used for privacy protection by anonymizing access. > This > should be addressed directly as it is likely to be one of the main use > cases as > we discovered in SAML which is the foundation for Shiboleth which allows > access > to resources across education campuses with privacy protections. > > The security and privacy implications of this approach are significant and > should be addressed in the document directly. In particular, what > expectations > has the client in this situation? In what ways might the identity of the > principal leak? > > More generally, one impact of the ability to chain authorizations across > domains is to allow parties to partition systems into smaller domains and > establish separation of roles/duties. > > Another question to be considered is the case in which the chaining is > recursive and whether there should be controls on the extent of the > chaining > and if it is necessary to prevent loops. > > It is easy to see how distribution of resources between trust domains A, > B, C > could result in C referring back to A. This is certainly bad if the loop > continues forever but could be valid in certain situations. If for example > Trust domain A holds a resource but trust domain B has a veto on its > release. > Unlike loops at the packet level which are always bad, the nature of the > request can change from hop to hop. > > > -- _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]
