Well sorry about that, I see that I got the assignment with 8 days to the end of last call. I read the draft and couldn't see anything requiring attention on the 9th with two days before last call, didn't hand the review in then because it looked like there should be something to say on a draft that is proposing to do chaining trust.
I only realized that I had been missing the bigger picture a few days ago and immediately handed in the review. On Fri, Jun 26, 2026 at 10:24 AM Brian Campbell <[email protected]> wrote: > 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.* -- Website: http://hallambaker.com/
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
