Re: [Id-event] [Secdispatch] Two topics of discussion for the Sec Dispatch session

[Phillip Hunt <[e-mail]>]

I was biting my tongue on this.

Tony and I submitted a push/pull bi-directional draft back when the original SET transmission draft was being broken in two push and poll methods. SSTP was designed so that either party could initiate connections and SETs could flow in either direction.  This is very much like how xmpp, imessage and other systems work - except with ack’ed transfers.

https://datatracker.ietf.org/doc/html/draft-hunt-secevent-sstp-00

AFAIK, there was never any exploration of the proposal because of pressure to close the WG and finish.  

We’re now back where we started only looking at a 3rd protocol.

Atul - I did submit a simple PR and an implementation (i2gosignals.io) that enables servers to register to both send and receive events using 8935 and 8936.  This is what I would prefer.

If the community really wants to go the new protocol route, please do this as a replacement for 8935/8936.  The goal should be interoperability around 1 protocol.

Phil
[e-mail]






> On Mar 19, 2024, at 5:52 PM, Michael Jones <[e-mail]> wrote:
> 
> I talked to the IANA folks on-site in Brisbane about 1 yesterday.  A request from an Area Director will be sufficient to change the title of the registry.
>  
>                                                                 -- Mike
>  
> From: Secdispatch <[e-mail] <mailto:[e-mail]>> On Behalf Of Atul Tulshibagwale
> Sent: Friday, March 15, 2024 5:02 PM
> To: [e-mail] <mailto:[e-mail]>
> Subject: [Secdispatch] Two topics of discussion for the Sec Dispatch session
>  
> Hi all,
> There are a couple of topics for which I have been seeking answers. I don't know if these are appropriate topics for the saag session next week. I will be attending remotely, and can prepare a presentation for the second point below if required.
> Errata to RFC 9493 There is an errata required for RFC9493 <https://datatracker.ietf.org/doc/rfc9493/> (Subject Identifiers for Security Event Tokens). The errata request is here <https://www.rfc-editor.org/errata/eid7727>. The errata requests a change to the registry created by this RFC, and there was consensus on the mailing list <https://mailarchive.ietf.org/arch/msg/id-event/-S-MsO2W6PeFF_O5kjP8om-7QNM/>that the errata should be accepted and the appropriate change reflected in the IANA registry. However, since the WG is completed, there was no clear identification of how to go about making these changes. If there is discussion required on this topic, we should have it in the meeting in Brisbane.
> New PushPull Delivery Proposal While we currently have specified Push delivery (RFC 8935 <https://datatracker.ietf.org/doc/html/rfc8935>) and Poll delivery (RFC 8936 <https://datatracker.ietf.org/doc/html/rfc8936>), we are seeing a clear requirement in the OpenID Shared Signals Working Group (SSWG) where a Transmitter is also a Receiver, and we would like to have a way of symmetric asynchronous event delivery. I would like to propose a new spec for this, but since the WG is closed, I wanted to know how to go about doing this. I realize the date for proposing new ideas for IETF 119 is past, but I can propose it after IETF 119 and discuss it in Vancouver. The topic I would like to discuss in IETF 119 is: What is the venue to propose this new idea for a combined "push and pull" delivery mechanism?
> Thanks,
> Atul
>  
> -- 
>  <https://sgnl.ai/>	
> Atul Tulshibagwale
> CTO
>  <https://linkedin.com/in/tulshi> <https://twitter.com/zirotrust> <mailto:[e-mail]>
>  
> _______________________________________________
> Id-event mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/id-event