Indeed, nice work, Stephen!
+1 to adding a Swagger definition as a committee note - that'll be a
huge help to future implementers.
Cheers,
Trey
On 07.02.2020 19:54:00, Bret Jordan wrote:
> Stephen,
>
> This is fantastic. Well done.
>
> I also really like the idea of tweaking the text around so that things like
> a swagger file can easily be created. I am also very supportive of us
> hosting and releasing a swagger file as an official committee note or other
> committee documents.
>
> Once again, well done. Thanks for doing all this.
>
> Bret
>
> Thanks,
> Bret
> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can
> not be unscrambled is an egg."
>
>
> On Fri, Feb 7, 2020 at 3:11 PM Stephen Russett <> wrote:
>
> > Hey everyone
> >
> > I just created a TAXII-Server for 2.1 at
> > https://github.com/StephenOTT/TAXII-Server.
> > This build is designed to be a generic implementation that provides the
> > API controls, but routes all requires to âprovidersâ that do the actual
> > handling/logic. See the Readme for a diagram explaining the setup. In
> > short it lets you route TAXII to a system like kafka or another endpoint,
> > so that those backing systems do not need to understand TAXII or even
> > produce STIX.
> >
> > This server comes with a OpenAPI/Swagger file that Client APIs can
> > consume, so devs can generate client API stubs for their code, and there is
> > also a ReDoc viewer for the swagger file. Check out the Readme for
> > screenshots and instructions.
> >
> > The build is in Kotlin, so you can download the ready to use jar from the
> > releases, or build it locally and run the jar or dockerfile.
> >
> > This project was put together as part of the preparation for STIX/TAXII
> > interop, so that devs preparing their implementations have a reference
> > build to work from and have a Client API swagger file to generate their
> > stubs from.
> >
> > It is still a WIP but all endpoints, and resources are setup with proper
> > responses, and error handling. See the issues for the task I am still
> > working on.
> >
> > A lessoned learned so far from converting the spec into a implementation
> > and a swagger file has been that the spec is currently a mix of
> > âImplementation text and internal spec rulesâ. They are mixed up in
> > various places throughout the spec, and not consistent. It would be great
> > if we could update the text in the spec so it has copy-and-pastable
> > sentences that are the âshort textâ that someone would copy into something
> > like a swagger file, and then the ~second paragraph is the internal spec
> > docs/rules. Section 3.7 of the spec that shows the description of the
> > Envelop properties is a good example of impl descriptions and internal spec
> > notes.
> >
> > If people have some time to donate to copy-and-paste from the spec into
> > the code, so we can complete the swagger file with all relevant
> > implementation details/reference docs, we could then move this data back
> > into the spec at a later date, when the implementation instructions/swagger
> > file is considered âcompleteâ.
> >
> > As always, feedback and contribution is welcomed!
> >
> > Have a great weekend.
> >
> > Stephen
> >
> >
> >
> >
> >
--
CERT.be / Centre for Cyber Security Belgium
Mail:
GPG: CA5B 29E4 937E 151E 2550 6607 AE9A 7FF2 8000 0E4E
Web: https://www.cert.be
--
Under the authority of the Prime Minister
rue de la Loi 16/Wetstraat 16, 1000 Brussels - Belgium
