The issue I recall with specifying URI in the defects work had to do with some URI’s are not downloadable artifacts, which the SECURITY external reference requires.
As RFC 3305 states “Thus, as we noted, "http:" is a URI scheme. An http URI is a URL.” Some URI’s represent downloadable artifacts, but some do not hence the reason for referring to a URL for downloadable artifacts used in the ExternalRef SECURITY case. Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™ <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com Email: <mailto:[email protected]> [email protected] Tel: +1 978-696-1788 From: [email protected] <[email protected]> On Behalf Of David Kemp Sent: Tuesday, May 10, 2022 9:49 AM To: [email protected] Cc: [email protected]; spdx-tech <[email protected]> Subject: Re: [spdx-tech] Simplifying Identities @William, That sounds reasonable, but it doesn't solve the problem of "Actor". If an Element is createdBy one Identity and Identity has Person/Organization/(tool?) subclasses, then there is no way to express that an Element was createdBy a person acting on behalf of an organization vs. the same person acting individually. And defining Element as created by 1..* Identities is a huge mess, including how to authenticate each of them. I like "identifiedBy" identifier properties, but I think each identifier should be tagged as person/organization/(tool?) rather than subclassing the Identity/Actor Element. @Jeff, what problem does the defects group perceive as resulting from not explicitly labeling a difference between URLs and URIs? The 2002 "contemporary view" of https://www.rfc-editor.org/rfc/rfc3305#section-2.2 still seems applicable today: The term "URL" does not refer to a formal partition of URI space; rather, URL is a useful but informal concept. URIs can refer to both "information resources" and "non-information resources" like namespaces (http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#note-informationResource). Non-information resources can never be located, while URIs for information resources can be persistent identifiers, temporary locators, or both. One argument for not creating an artificial dichotomy is that any non-locator URI becomes a locator as soon as anyone deploys a resolver service, and that such resolvers are used in practice to locate namespaced information resources using SPARQL. So I would ask about a proposal to define separate property names: what problem does it solve? Regards, Dave On Mon, May 9, 2022 at 11:34 PM Jeff Schutt (jefschut) via lists.spdx.org <http://lists.spdx.org> <[email protected] <mailto:[email protected]> > wrote: Hey William, Initial reactions: * I like the simplicity this introduces wrt consolidating various types of identifiers in the model. * I don’t like that this continues to co-mingle identifiers and locators, and perpetuates some of the confusion caused by the way ExternalReferences are defined in v2.x. Two observations of previous SPDX decisions made: 1. The 3.0 model uses “ArtifactURI” rather than the subset of “ArtifactURL” 2. In the Defects WG we accepted this identifier/locator co-mingling as part of the patch to v2.3 with the expectation that we would resolve it by ensuring identifiers and locators are separate entities in v3.0. How would you suggest accommodating this separation in the proposal? One option would be to have “identifiedBy” and “locatedBy” both be on “Element”. { "SPDXID": "urn:spdx.dev:spdx-tools-3.0.0", "name": "spdx-tools-3.0.0", "locatedBy": [ {"type": "PURL", "locator": "pkg:..."} ], "identifiedBy": [ {"type": "cpe22", "identifier": "..."}, {"type": "SWHID", "identifier": "..."} ] } - Jeff From: <[email protected] <mailto:[email protected]> > on behalf of "William Bartholomew (CELA) via lists.spdx.org <http://lists.spdx.org> " <[email protected] <mailto:[email protected]> > Reply-To: "[email protected] <mailto:[email protected]> " <[email protected] <mailto:[email protected]> > Date: Monday, May 9, 2022 at 8:00 PM To: spdx-tech <[email protected] <mailto:[email protected]> > Subject: [spdx-tech] Simplifying Identities I experimented with something around identities and I'm really liking the simplicity, so I wanted to run it by you to get your thoughts: * We keep "Identity" element with subclasses of "Person" and "Organization" (I'm ignoring "Tool" for right now). * Introduce a new data type "Identifier" which could have subtypes like "EmailAddress" and "Login". * Add a property to "Element" called "identifiedBy" which is a list of zero or more "Identifier". This means we can have a Person that looks like this: { "SPDXID": "urn:github.com:users:iamwillbar", "type": "Person", "name": "William Bartholomew", "identifiedBy": [ {"type": "EmailAddress", "email": "[email protected] <mailto:[email protected]> "}, {"type": "Account", "authority": "github.com <http://github.com> ", "username": "iamwillbar"} ] } This then got me thinking that "artifactUrl" on "Artifact" is just another form of "Identifier", which means we could remove that property and so a "Package" could look like this: { "SPDXID": "urn:spdx.dev:spdx-tools-3.0.0", "name": "spdx-tools-3.0.0", "identifiedBy": [ {"type": "PURL", "locator": "pkg:..."} ] } What does that remind you of? "ExternalReferences", so we can then remove those and merge that concept into identifiers: { "SPDXID": "urn:spdx.dev:spdx-tools-3.0.0", "name": "spdx-tools-3.0.0", "identifiedBy": [ {"type": "PURL", "locator": "pkg:..."}, {"type": "cpe22", "locator": "..."}, {"type": "SWHID", "locator": "..."} ] } And because "identifiedBy" is on "Element" any new types we add in the future can also have identifiers attached to them: { "SPDXID": "urn:cve:12345", "name": "tkvideo has a memory issue in playing videos", "identifiedBy": [ {"type": "CVE", "locator": "CVE-2022-24902"} ] } What do you all think? Sent from Outlook <http://aka.ms/weboutlook> -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4499): https://lists.spdx.org/g/Spdx-tech/message/4499 Mute This Topic: https://lists.spdx.org/mt/91005596/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
