Skip to content

Proposal for connecting ONVIF and C2PA #508

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 13 commits into
base: development
Choose a base branch
from
255 changes: 252 additions & 3 deletions doc/MediaSigning.xml
Original file line number Diff line number Diff line change
Expand Up @@ -4,19 +4,19 @@
<info>
<title>Media Signing Specification</title>
<titleabbrev>Media Signing</titleabbrev>
<releaseinfo>24.12</releaseinfo>
<releaseinfo>25.06</releaseinfo>
<author>
<orgname>ONVIF™</orgname>
<uri>www.onvif.org</uri>
</author>
<pubdate> December, 2024</pubdate>
<pubdate> June, 2025</pubdate>
<mediaobject>
<imageobject>
<imagedata fileref="media/logo.png" contentwidth="60mm"/>
</imageobject>
</mediaobject>
<copyright>
<year>2022-2024</year>
<year>2022-2025</year>
<holder>ONVIF™ All rights reserved.</holder>
</copyright>
<legalnotice>
Expand Down Expand Up @@ -48,6 +48,14 @@
</author>
<revremark>First release</revremark>
</revision>
<revision>
<revnumber>25.06</revnumber>
<date>Dec 2025</date>
<author>
<personname>Ottavio Campana</personname>
</author>
<revremark>Added Annex D for C2PA interoperability</revremark>
</revision>
</revhistory>
</info>
<chapter xml:id="chapter_zhs_njq_bwb">
Expand Down Expand Up @@ -1379,5 +1387,246 @@
<para>IETF RFC 3447 Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1</para>
<para role="reference">&lt;<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://tools.ietf.org/rfc/rfc3447.txt"/>&gt;</para>
<para>C2PA Specifications Version 2.1</para>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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">&lt;<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://c2pa.org/specifications/specifications/2.1/index.html"/>&gt;</para>
</appendix>
<appendix>
<title>C2PA interoperability</title>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

  1. 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.
  2. 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.
  3. 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.
  4. 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?

<para>In C2PA, provenance generally refers to the facts about the history of a piece of digital
content assets (image, video, audio recording, document). Content Credentials enables the
secure binding of statements of provenance data to instances of content. These provenance
statements are called assertions in a Content Credential. They may include assertions about
who created the content and how, when, and where it was created. </para>
<para>This Annex defines the assertions necessary to embed an ONVIF-compliant digitally signed
video feed into a C2PA compliant file.</para>
<section>
<title>Overview</title>
<para>The ONVIF-defined assertion are split in two group in order to be able to keep track of
two possible use cases:</para>
<itemizedlist>
<listitem>
<para>The video is generated and signed by a device, but the MP4 file is generated by a
client.</para>
</listitem>
<listitem>
<para>The video is generated and signed by a device that support local recording and that
generates the MP4 autonomously.</para>
</listitem>
</itemizedlist>
<para>Therefore, the <emphasis>org.onvif.c2pa.device</emphasis> assertion must always be
populated by the device, while the <emphasis>org.onvif.c2pa.client</emphasis> assertion shall
be populated either by the client or by the device.</para>
</section>
<section>
<title>C2PA assertions</title>
<para>The following C2PA assertions are defined to extend the standard C2PA ones:</para>
<para>
<table frame="all">
<title>ONVIF-defined C2PA assertions</title>
<tgroup cols="4" align="left">
<colspec colname="c1" colnum="1"/>
<colspec colname="c2" colnum="2"/>
<colspec colname="c3" colnum="3"/>
<colspec colname="c4" colnum="4"/>
<thead>
<row>
<entry>
<para>Type</para>
</entry>
<entry>
<para>Assertion</para>
</entry>
<entry>
<para>Schema</para>
</entry>
<entry>
<para>Serialization</para>
</entry>
</row>
</thead>
<tbody>
<row>
<entry>
<para>ONVIF device information</para>
</entry>
<entry>
<para>org.onvif.c2pa.device</para>
</entry>
<entry>
<para>ONVIF</para>
</entry>
<entry>
<para>JSON-LD</para>
</entry>
</row>
<row>
<entry>
<para>ONVIF client information</para>
</entry>
<entry>
<para>org.onvif.c2pa.recorder</para>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It says recorder. Is that correct or should it be client

</entry>
<entry>ONVIF</entry>
<entry>
<para>JSON-LD</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
</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>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<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>
<table frame="all">
<title>ONVIF-defined C2PA device assertions</title>
<tgroup cols="4" align="left">
<colspec colname="c1" colnum="1"/>
<colspec colname="c2" colnum="2"/>
<colspec colname="c3" colnum="3"/>
<colspec colname="c5" colnum="4"/>
<thead>
<row>
<entry>
<para>Name</para>
</entry>
<entry>
<para>Type</para>
</entry>
<entry>
<para>Required</para>
</entry>
<entry>Property description</entry>
</row>
</thead>
<tbody>
<row>
<entry>
<para>FirmwareVersion</para>
</entry>
<entry>
<para>String</para>
</entry>
<entry>
<para>No</para>
</entry>
<entry>
<para>The version of the FW running on 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></entry>
</row>
<row>
<entry>
<para>SerialNumber</para>
</entry>
<entry>
<para>String</para>
</entry>
<entry>No</entry>
<entry>
<para>The serial number of 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>
</entry>
</row>
<row>
<entry>
<para>Manufacturer</para>
</entry>
<entry>
<para>String</para>
</entry>
<entry>No</entry>
<entry>
<para>The manufacturer of 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>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

</entry>
</row>
<row>
<entry>
<para>Certificate</para>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

</entry>
<entry>
<para>String</para>
</entry>
<entry>Yes</entry>
<entry><para>The certificate chain in PEM format</para>
<para>If this field is populated, it must match the value in the <xref linkend="section_v3s_njq_bwb"/> tag.</para></entry>
</row>
</tbody>
</tgroup>
</table>
</para>
</section>
<section>
<title>ONVIF client information</title>
<para>This assertion is used to embed in the C2PA file information about the client that exported the signed video feed.</para>
<para>
<table frame="all">
<title>ONVIF-defined C2PA recorder assertions</title>
<tgroup cols="4" align="left">
<colspec colname="c1" colnum="1"/>
<colspec colname="c2" colnum="2"/>
<colspec colname="c3" colnum="3"/>
<colspec colname="c5" colnum="4"/>
<thead>
<row>
<entry>
<para>Name</para>
</entry>
<entry>
<para>Type</para>
</entry>
<entry>
<para>Required</para>
</entry>
<entry>Property description</entry>
</row>
</thead>
<tbody>
<row>
<entry>
<para>SoftwareVersion</para>
</entry>
<entry>
<para>String</para>
</entry>
<entry>
<para>No</para>
</entry>
<entry>
<para>The version of the software that generated the C2PA-compliant MP4
file.</para>
<para>If this field is populated, it must match the value in the <xref linkend="section_o3s_njq_bwb"/> tag.</para></entry>
</row>
<row>
<entry>
<para>Software</para>
</entry>
<entry>
<para>String</para>
</entry>
<entry>No</entry>
<entry>The name of the software that generated the C2PA-compliant MP4
file.</entry>
</row>
<row>
<entry>
<para>ExportUnitMac</para>
</entry>
<entry>
<para>String</para>
</entry>
<entry>Yes</entry>
<entry><para>The unique physical MAC address of the entity that generated the MP4 file.</para></entry>
</row>
</tbody>
</tgroup>
</table>
</para>
</section>
</section>
</appendix>
</book>