[saag] Re: Requesting feedback on Push-Based Delivery For Mu ltiple Security Event Token (SET) Using HTTP
Aaron Parecki <[email protected]> Fri, 19 Dec 2025 17:01:24 -0800
| Newsgroups | gmane.ietf.saag |
|---|---|
| Message-ID | <CAGBSGjpgMSrD=eC8Hhg_MK3j88L8gctXYuRKrCT1SrY5h-MyDg@mail.gmail.com> |
Hi Atul, thanks for your review. Responses inline. Hi Apoorva and Aaron, > Thanks for sharing this draft. Here are my comments: - In Section 1, paragraph starting: "Push-Basd delivery for multiple > SETs is intended to help in the following scenarios:", you should add > another reason: The receiver wants to acknowledge or provide error > responses to previously received SETs, but wants to do so > asynchronously, > not within the response to the same HTTP POST in which it received the > SET. > Great point, thank you. This has been added. > - The "sending zero SETs" is a good option in this spec. Should there be > any guidance (non-normative) that a Transmitter should periodically send > zero SETs if it has no SETs to send or retry sending, but it hasn't > received acknowledgement for previously sent SETs? Right now section 5 > only > talks about retries. I can envision a case where a Transmitter is simply > waiting for some time before it decides it needs to retry. Thanks for the suggestion, this helps clarify one of the other comments in an earlier review as well. This draft will be really valuable to the OpenID Shared Signals Working > Group (SSWG) because right now SSF transmitters can only send one SET at a > time using Push Delivery, and SSF Receivers need to either positively or > negatively acknowledge those SETs synchronously within that HTTP call. Atul --- Aaron Parecki _______________________________________________ saag mailing list -- [email protected] To unsubscribe send an email to [email protected]