[urn] Re: Registration for `c2pa` URN

[Leonard Rosenthol <[e-mail]>]

I thought about doing that, but since RFC 9562 didn’t do it – I figured it wasn’t allowed for some reason.

Leonard

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


Hi Leonard, thanks for the quick turnaround.

To simplify the ABNF, you could re-use some of the rules from RFC 3986
or RFC 5234 rather than (apparently) redefining them here.

Other than that, it looks good to me.

Peter

On 8/1/24 12:58 PM, Leonard Rosenthol wrote:
> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fc2pa.org%2Fspecifications%2Fspecifications%2F2.1%2Fspecs%2FC2PA_Specification.html%23_unique_identifiers&data=05%7C02%7Clrosenth%40adobe.com%7C4a00b8a175fa452bde2408dcb25ed445%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638581367569277617%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=9rBAhiGg3vy2st66CDmMH0I%2BjICe7%2BhoXjUi6JGr2e4%3D&reserved=0<https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html#_unique_identifiers> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fc2pa.org%2Fspecifications%2Fspecifications%2F2.1%2Fspecs%2FC2PA_Specification.html%23_unique_identifiers&data=05%7C02%7Clrosenth%40adobe.com%7C4a00b8a175fa452bde2408dcb25ed445%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638581367569291331%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=QS4o5GL%2F8CmgEyyO64JNB4JM7smDzea2H0hlGNyEVWw%3D&reserved=0<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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fc2pa.org%2Fspecifications%2Fspecifications%2F2.1%2Fspecs%2FC2PA_Specification.html%23_information_security&data=05%7C02%7Clrosenth%40adobe.com%7C4a00b8a175fa452bde2408dcb25ed445%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638581367569299706%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=75jPvqVwa9EPv%2Bg9kYY9ih7B0IG24C8v9ch2ZL6RcCI%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fc2pa.org%2Fspecifications%2Fspecifications%2F2.1%2Fspecs%2FC2PA_Specification.html%23_information_security&data=05%7C02%7Clrosenth%40adobe.com%7C4a00b8a175fa452bde2408dcb25ed445%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638581367569305741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=OpLLVhlHfvfX6XTXIi5cMHMrUgtVEIf536P8blcSw7g%3D&reserved=0<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://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%7C4a00b8a175fa452bde2408dcb25ed445%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638581367569310893%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2Ble45Amx7pJw1NGQw7VcbTx6Fnb7IdoDXnli%2FpeWUE4%3D&reserved=0<https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html> <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%7C4a00b8a175fa452bde2408dcb25ed445%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638581367569315849%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=13IoUimLrQzpq7x9btLew5h26%2F%2F5RskucC85V5CH%2BpM%3D&reserved=0<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] <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%7C4a00b8a175fa452bde2408dcb25ed445%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638581367569322489%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=EC4nf%2FKJlFd%2FObrLd2YxdMNmlpzV7%2BpMcj2X0IPCwlg%3D&reserved=0<https://c2pa.org/specifications/specifications/2.0/specs/C2PA_Specification.html#_information_security> <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%7C4a00b8a175fa452bde2408dcb25ed445%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638581367569327932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=vbRrtLI8NAkg3q%2FwT2Z50ikfsq9Yt52H8HWXC1gBIco%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%7C4a00b8a175fa452bde2408dcb25ed445%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638581367569334597%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2B5xspyCmELLrJsmwbV2hJQmoCC6B5lO94P948hqvcF8%3D&reserved=0<https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html> <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%7C4a00b8a175fa452bde2408dcb25ed445%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638581367569340845%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=JLize5PZoIg4o%2Fjme4XEReUyHWLDV%2BpbutHhl3LCc4w%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 -- [e-mail]
> To unsubscribe send an email to [e-mail]