docs: endorsement lifecycle management API#74
Conversation
API spec for activation/deactivation of triples using CoRIM IDs, CoMID IDs, or CoSERV query. Co-authored-by: Dhanus M Lal <Dhanus.MLal@fujitsu.com> Co-authored-by: Kumar, Atul <Atul.Kumar@fujitsu.com> Signed-off-by: Kumar, Atul <Atul.Kumar@fujitsu.com>
- use coserv data model primitives to create endorsements lifecycle management (ELM) queries >[!TODO] > Migrate from application/problem+json (RFC 9457) to > applicaton/concise-problem-details+cbor (RFC 9290). > This change should be applied to other endpoints > (and services) to maintain consistency in the response > encondings. Better to address it in a future PR when > consensus is reached on the response format(s). Signed-off-by: Kumar, Atul <Atul.Kumar@fujitsu.com>
thomas-fossati
left a comment
thomas-fossati
left a comment
There was a problem hiding this comment.
Looks good, thanks.
Before merging, I’d like to discuss the position of the profile in the query.
| Following is the CDDL format for an ELM query: | ||
| ``` | ||
| elm-query = { | ||
| &(profile: 0) => coserv.profile |
There was a problem hiding this comment.
The profile does not belong in the rim query. I think it makes more sense to move it into the environment query.
There was a problem hiding this comment.
I used this diagnostic notation as a reference: rv-rim-query.diag, where the profile is included in the rim query. I'm not sure why it makes sense there but not here.
Slightly on the same topic, I would like to confirm if it's okay for the ELM query to diverge from the CoSERV data model beyond the fields that it imports? For example, I have removed coserv.result-type from the query because it is not useful here. Removing the profile from the rim query would be a step in the same direction.
There was a problem hiding this comment.
I used this diagnostic notation as a reference: rv-rim-query.diag, where the profile is included in the rim query. I'm not sure why it makes sense there but not here.
here, we are not constrained by the wrapping choices made by coserv, we have a bit more leeway to rearrange the objects in the most logical way for the use case… which segways into:
Slightly on the same topic, I would like to confirm if it's okay for the ELM query to diverge from the CoSERV data model beyond the fields that it imports?
Yes.
For example, I have removed
coserv.result-typefrom the query because it is not useful here. Removing the profile from the rim query would be a step in the same direction.
Yes.
There was a problem hiding this comment.
FYI: @thomas-fossati so then because we have can diverge from the CoSERV data model please note in implementation we might have to write new structs and probably modify current coserv code so that these fields can be made optional.
4 participants
API spec for activation/deactivation of triples using CoRIM IDs, CoMID IDs, or CoSERV query.
This is the SPEC whose implementation will resolves Github issue: veraison/services#402