Proposal for connecting ONVIF and C2PA #508
Conversation
22.12 release
23.06 Release
23.12 release
Master Update
…ONVIF digital media signing specs
| <entry> | ||
| <para>The manufacturer the device that generated the RTSP stream with the | ||
| digital signatures.</para> | ||
| <para>If this field is populated, it must match the value in the <xref linkend="section_r3s_njq_bwb"/> tag.</para> |
There was a problem hiding this comment.
The multiple paragraphs don't seem to render properly in the tables according to
https://developer.onvif.org/pub/specs/branches/video/c2pa/doc/MediaSigning.xml
Not sure if that's a general issue of specific to the developer website?
| </para> | ||
| <section> | ||
| <title>ONVIF device information</title> | ||
| <para>This assertion is used to embed in teh C2PA file informtion about the device that generated the signed video feed.</para> |
There was a problem hiding this comment.
| <para>This assertion is used to embed in teh C2PA file informtion about the device that generated the signed video feed.</para> | |
| <para>This assertion is used to embed in the C2PA file information about the device that generated the signed video feed.</para> |
| <para>ONVIF client information</para> | ||
| </entry> | ||
| <entry> | ||
| <para>org.onvif.c2pa.recorder</para> |
There was a problem hiding this comment.
It says recorder. Is that correct or should it be client
| @@ -1379,5 +1387,246 @@ | |||
| <para>IETF RFC 3447 Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications | |||
| Version 2.1</para> | |||
| <para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://tools.ietf.org/rfc/rfc3447.txt"/>></para> | |||
| <para>C2PA Specifications Version 2.1</para> | |||
There was a problem hiding this comment.
Do we need to specify a version? It would be great if don't have to maintain this to get the latest C2PA version all the time, or do we want to stay at 2.1?
| <para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://c2pa.org/specifications/specifications/2.1/index.html"/>></para> | ||
| </appendix> | ||
| <appendix> | ||
| <title>C2PA interoperability</title> |
There was a problem hiding this comment.
I think it is a good idea to put this here in an annex of Media Signing, but there are alternatives.
Here are a few example use cases
- A client would like to make an exported recording file C2PA compliant, but the device used does not support ONVIF Media Signing. Then the assertions do not apply and it is also weird to put the information in the Media Signing spec. Probably better fit in Export File Format.
- Same use case as in 1 above, but the device does support ONVIF Media Signing. If this annex is put in Export File Format the assertions could be written to support both use cases.
- A device stores recording files locally on for example SD-card, but the device does not support ONVIF Media Signing. Now there are two options
a) Use both ONVIF Media Signing and make recording C2PA compliant using proposal in this PR.
b) Skip ONVIF Media Signing and use only C2PA
This is again maybe more suited in Export File Format if we want to deal with C2PA only. - Device push to cloud. Each chunk could be made C2PA compliant and similar to the other use cases there is an alternative to do it on top of ONVIF Media Signing or separately.
I'm skipping for now discussions on efficiency in terms of bitrate increase and how using C2PA scales with devices. The main question is if this proposal PR should include also C2PA assertions without ONVIF Media Signing?
| </row> | ||
| <row> | ||
| <entry> | ||
| <para>Certificate</para> |
There was a problem hiding this comment.
Adding the certificate chain is a good idea, and probably some kind of minimum, or could it be enough to add a hash of the certificate chain to lower the size?
If the video is signed with a "user provisioned key" should we add both certificate chains like we propose for the certificate SEI?
I see one problem with only adding the certificate chain because it is the same for all videos from that camera. For provenance that is enough, but if we also want to add some kind of "check" of authenticity we need something unique from the video, for example, hashes of the SEI frames. We could add another entry here for that.
Co-authored-by: jmelancongen <[email protected]>
Co-authored-by: jmelancongen <[email protected]>
Co-authored-by: jmelancongen <[email protected]>
Co-authored-by: jmelancongen <[email protected]>
Co-authored-by: jmelancongen <[email protected]>
Co-authored-by: jmelancongen <[email protected]>
Co-authored-by: jmelancongen <[email protected]>
|
@ocampana-videotec at document Preview for this PR Media signing xml is not part of the index for review. Not sure if you have any control over this. https://developer.onvif.org/pub/specs/branches/video/c2pa/doc/index.html |
This is an initial proposal to specify how to use a digitally signed RTSP stream to create a C2PA-compliant file and to achieve end-to-end integrity validation, from the camera to the final file used in trials.