[urn] Re: Registration for `c2pa` URN

[Leonard Rosenthol <[e-mail]>]

Here is the revised registration proposal.   The links to 2.1 will be live tomorrow (2-Aug-2024).

Leonard
Namespace Identifier:  c2pa

Version:  1

Date:  2024-07-30

Registrant:
Leonard Rosenthol, on behalf of C2PA (Coalition for Content Provenance and Authenticity)
[e-mail]<mailto:[e-mail]>, 1-215-808-4978

Purpose:

Each C2PA Manifest (aka Content Credential) created to incorporate provenance information about a given asset is given a unique identifier which has historically been an incorrectly formatted UUID URN.  This proposal, in conjunction with an updated specification, will define a new `c2pa` URN namespace for this purpose.

The `c2pa` URN will consist of a UUID URN (as per RFC 9562), with the namespace changed to 'c2pa' and additional information that is specific to C2PA added.  These URNs are non-resolvable, serving as unique identifiers. In this way, the ability to unambiguously compare them is of significant importance.

Syntax:

A `c2pa` URN shall consist of two mandatory and two optional components, in the following order, with `:`'s between each section.

                - URN identifier (`urn:c2pa`): REQUIRED
                - UUID v4, in string representation (as per RFC 9562, section 4): REQUIRED
                - Claim Generator identifier string : OPTIONAL
                - Version and Reason string : OPTIONAL

When present, the "Claim Generator identifier" string shall consist of no more than 32 characters from the ASCII range (as per RFC 20), but which are not Control Characters (RFC 20, 5.2), Graphic Characters (RFC 20, 5.3), the `:` or the `_`.

When present, the "Version and Reason" string shall consist of a `v` followed by a monotonically increasing integer, starting with 1, followed by an underscore (`_`) and then an integer representing the reason for the re-labeling.

An ABNF for a `c2pa` URN looks like:
                c2pa_urn = c2pa-namespace UUID [":" claim-generator] [":" version-reason]

                c2pa-namespace = "urn:c2pa:"

                ; this definition is taken from RFC 9562
                UUID     =  4hexOctet "-"
                                                                2hexOctet "-"
                                                                2hexOctet "-"
                                                                2hexOctet "-"
                                                                6hexOctet
                hexOctet = HEXDIG HEXDIG
                DIGIT    = %x30-39
                HEXDIG   = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"

                ; ASCII, but not Control Characters, Graphic Characters, `:` or `_`
                visible-char-except-space-colon-underscore = %x21-2B / %x2D-3A / %x3C-7E / %x80-FF

                ; claim-generator-identifier is a string of
                ;               1 to 32 visible-char-except-space-colon-underscore
                claim-generator = ":" claim-generator-identifier
                claim-generator-identifier = 1*32visible-char-except-space-colon-underscore

                ; version-reason is a string consisting of a "v" followed by
                ;               a positive integer, an underscore and a second positive integer
                version-reason = ":v" version "_" reason
                version = 1*DIGIT
                reason = 1*DIGIT

EXAMPLES:

                - `urn:c2pa:F9168C5E-CEB2-4FAA-B6BF-329BF39FA1E4`
                - `urn:c2pa:F9168C5E-CEB2-4FAA-B6BF-329BF39FA1E4:acme`
                - `urn:c2pa:F9168C5E-CEB2-4FAA-B6BF-329BF39FA1E4:acme:v2_1`
                - `urn:c2pa:F9168C5E-CEB2-4FAA-B6BF-329BF39FA1E4:v2_1`


Assignment:

URNs conforming to this scheme are self-assigned, based on the creation of the UUID (as per RFC 9562) and the optional inclusion of the Claim Generator identifier string and Version and Reason. This process is described at https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html#_unique_identifiers


Security and Privacy:

No known security or privacy issues exist for this specific URN, however, the C2PA specification maintains a "Information Security" section (https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html#_information_security) which documents any known threats and harms related to the core C2PA specification.


Interoperability:

A standard UUID URN can be "losslessly upgraded" to a `c2pa` UUID, if there were to exist a workflow that required doing so.  Beyond that, no known concerns or requirements around interoperability exist.

Resolution:

As mentioned earlier in this document, these URNs are non-resolvable, serving as unique identifiers. In this way, the ability to unambiguously compare them is of significant importance.


Documentation:

https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html

Additional Information:  NONE

Revision Information:  N/A




From: Dale R. Worley <[e-mail]>
Date: Thursday, August 1, 2024 at 2:23 PM
To: Leonard Rosenthol <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [urn] Registration for `c2pa` URN
EXTERNAL: Use caution when clicking on links or opening attachments.


The overall concept looks fine.  I have the following comments.

> Namespace Identifier:  c2pa
>
> Version:  1
>
> Date:  2024-07-30
>
> Registrant:
> Leonard Rosenthol, on behalf of C2PA (Coalition for Content Provenance
> and Authenticity)
> [e-mail]<mailto:[e-mail]>, 1-215-808-4978

As Peter says, the contact identification should be chosen to be stable
as long as possible.

> Purpose:
>
> Each C2PA Manifest (aka Content Credential) created to incorporate
> provenance information about a given asset is given a unique
> identifier which has historically been an incorrectly formatted UUID
> URN.  This proposal, in conjunction with an updated specification,
> will define a new `c2pa` URN syntax for this purpose.

Change "URN syntax" to "URN namespace".

> The `c2pa` URN will consist of a UUID URN (as per RFC 9562) with

You probably want to add "the namespace changed to 'c2pa', with" here.

> additional information, specific to C2PA added.  These URNs are
> non-resolvable, simply serving as unique identifiers. In this way, the
> ability to unambiguously compare them is of significant importance.

Though it seems from the 3rd and 4th fields, the URNs aren't *just*
unique identifiers, the identifier is tagged with some semantic
information.  So you might want to expand on that here.

> Syntax:
>
> A `c2pa` URN shall consist of two mandatory and two optional
> components, in the following order, with `:`'s between each section.
>
>                 - URN identifier (`urn:c2pa`): REQUIRED
>                 - UUID v4, in string representation (as per RFC 9562, section 4): REQUIRED
>                 - Claim Generator identifier string : OPTIONAL
>                 - Version and Reason string (as described below) : OPTIONAL

You really ought to provide ABNF here.  E.g., this text says that the
3rd and 4th parts are both optional, but it's not clear, if only one of
them is present in a URN, which one is present.  It appears from the
examples that if the 4th part is present, then the 3rd (or at least the
colon that starts it) must be.  What you're looking for is something
like:

c2pa_urn = "urn:c2pa:"
           UUID         ; from RFC 4122
           [ ":" [ claim_generator ]
             [ ":" version_reason ] ]

Of course, we need some idea what the syntax of "claim_generator" is.
At least it must not contain a colon!

> When present, the "Version and Reason" string shall consist of a `v`
> followed by a monotonically increasing integer, starting with 1,
> followed by an underscore (`_`) and then an integer representing the
> reason for the re-labeling.

version_reason = version "_" reason
version        = "v" %31-39 *%30-39    ; "v" and a positive decimal integer (see RFC 2234)

But it's not clear what the syntax or semantics of "reason" is.

> EXAMPLES:
>
>                 - `urn:c2pa:F9168C5E-CEB2-4FAA-B6BF-329BF39FA1E4`
>                 - `urn:c2pa:F9168C5E-CEB2-4FAA-B6BF-329BF39FA1E4:acme`
>                 - `urn:c2pa:F9168C5E-CEB2-4FAA-B6BF-329BF39FA1E4:acme:v2_1`

It's always good to have examples!

> Assignment:
>
> URNs conforming to this scheme are self-assigned, based on the
> creation of the UUID (as per RFC 9562) and the optional inclusion of
> the Claim Generator identifier string and Version and Reason.

It would be helpful to have some description of the syntax and semantics
of the claim_generator and reason fields.  If the C2PA web specification
has a concise description, a link to that would be sufficient.

> Security and Privacy:
>
> No known security or privacy issues exist.

As Peter says, not only does
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fc2pa.org%2Fspecifications%2Fspecifications%2F2.0%2Fspecs%2FC2PA_Specification.html%23_information_security&data=05%7C02%7Clrosenth%40adobe.com%7C75ff36116eaa4590625608dcb256fab2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638581333851216505%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=MvnKaCNhSylJNrm0Y%2FoirFWaBgZq4Mhq3%2BeHZ8X9CF0%3D&reserved=0<https://c2pa.org/specifications/specifications/2.0/specs/C2PA_Specification.html#_information_security>
give extensive security discussion (which might just be pointed to here)
but its existence shows that there *are* known security issues,
contradicting this text.

> Interoperability:
>
> A standard UUID URN can be "losslessly upgraded" to a `c2pa` UUID, if
> there were to exist a workflow that required doing so.  Beyond that,
> no known concerns or requirements around interoperability exist.
>
> Resolution:  N/A

You might want to move the sentences "These URNs are non-resolvable ..."
to this section.

> Documentation:  https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fc2pa.org%2Fspecifications%2Fspecifications%2F2.1%2Fspecs%2FC2PA_Specification.html&data=05%7C02%7Clrosenth%40adobe.com%7C75ff36116eaa4590625608dcb256fab2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638581333851225220%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=x5Su58QKqIG9cJJS1UN7Xv8SkLV1%2F0bdAB9ouEjUm6Q%3D&reserved=0<https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html>
>
> NOTE: Version 2.1 is not yet published but will contain this documentation when published

How shall we handle this?  It's not proper to register a URN namespace
if its references do not exist.  Is there an earlier version of the
specification which is "good enough" to link to as documentation?

Of course, when new version(s) of the C2PA spec are published, it's easy
enough to register a new version of the URN to update the documentation
pointer.

> Additional Information:  NONE
>
> Revision Information:  N/A

Dale