[urn] Re: Registration for `c2pa` URN

Dale – GREAT feedback, thanks!

I am working on an update including your and Peter’s comments.  And since we will be putting out a draft of 2.1 tomorrow, I will put the link for that in here!

Leonard

From: Dale R. Worley <[email protected]>
Date: Thursday, August 1, 2024 at 2:23 PM
To: Leonard Rosenthol <[email protected]>
Cc: [email protected] <[email protected]>
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)
> [email protected]<mailto:[email protected]>, 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

_______________________________________________
urn mailing list -- [email protected]
To unsubscribe send an email to [email protected]