[urn] Re: Registration for `c2pa` URN

[Peter Saint-Andre <[e-mail]>]

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://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html#_unique_identifiers <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 <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 <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%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 -- [e-mail]
> To unsubscribe send an email to [e-mail]