Extend service dataflow support #194
Conversation
Signed-off-by: Steve Springett <steve@springett.us>
stevespringett
changed the title
stevespringett
changed the title
stevespringett
added
request for comment
RFC notice sent
There was a problem hiding this comment.
What i see:
- JSON had a braking change: renamed
/definitions/dataFlow->/definitions/dataFlowDirection - XML had no breaking change, but got a new optional element structure, while the old one was deprecated
- the ProtoBuff just got a documentation added.
This inconsistency is strange. Why not have drastic changes for everyone target? Or non-breaking JSON?
if you wanted those JSON changes less breaking:
- rename the element
- create a new element with the exact old name,
which has a$refto the renamed element,
and a documentation that articulates that this definition is deprecated in favor of the new name
While the definition was renamed, the change is NOT breaking in that all of the service tests from v1.4 validate with v1.5. I tested against valid-service-1.4.json |
…ated all examples to include name/description. Signed-off-by: Steve Springett <steve@springett.us>
Signed-off-by: Steve Springett <steve@springett.us>
|
Ping @laurentsimon @expede I’m wondering of there’s opportunity for alignment across this, the scorecard probe work, and ipvm-wg/spec#8 Also related: in-toto/attestation#165 |
| "endpoints": [ | ||
| "https://ms-1.example.com" | ||
| ], | ||
| "authenticated": true, |
There was a problem hiding this comment.
I wonder if this might be a place where the https://identity.foundation/presentation-exchange/ spec could be used to specify the requirements around authentication. We could imagine a world where scorecard probes are hosted as microservices executed as an IPVM affect.
There was a problem hiding this comment.
Just spitballin here. In our hypothetical example we’d be looking at a CycloneDX dataflow of scorecard itself, attempting to execute the probes via IPVM.
There was a problem hiding this comment.
I like your thinking @pdxjohnny. 😄 We've wanted to be able to document authentication requirements in CycloneDX for a while now, but as you know, it's not a simple task. We haven't had an opportunity to research existing specs yet, but the presentation exchange format looks interesting and may just work. Historically, we've supported links out to other schemas/files via CycloneDX external references. We're doubling the number of external references supported in the upcoming v1.5 release. Most of the new external references for v1.5 are here. Integration could be as simple as adding a new one for authentication requirements, or we may choose a more integrated approach. Regardless, I'd recommend creating a new ticket to discuss this, as this ticket is specific to dataflow enhancements.
There was a problem hiding this comment.
Sounds great :D will do! Thank you for your response
|
re: #194 (review) |
Expanded service dataflow support. Closes #191