[urn] Re: Registration for `c2pa` URN
Peter Saint-Andre <[email protected]>
| Newsgroups | gmane.ietf.urn |
|---|---|
| Message-ID | <[email protected]> |
Well, we did it in Section 2 of RFC 8141 (re-using alphanum, fragment, and pchar from RFC 3986), so it's a fine way to do things, but not necessary. On 8/1/24 1:22 PM, Leonard Rosenthol wrote: > 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 <[email protected]> > *Date: *Thursday, August 1, 2024 at 3:19 PM > *To: *Leonard Rosenthol <[email protected]>, Dale R. Worley > <[email protected]> > *Cc: *[email protected] <[email protected]> > *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) >> >> [email protected] <mailto:[email protected] <mailto:[email protected]>>, 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 <[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] <mailto:[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%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 -- [email protected] >> To unsubscribe send an email to [email protected] > _______________________________________________ urn mailing list -- [email protected] To unsubscribe send an email to [email protected]