I didn't give the CVE example a lot of thought, it was meant to be demonstrative rather than a proposal so don't read too much into that one.
On Actor, I should have clarified, this proposal isn't meant to replace the other proposal, they can be combined (e.g. createdBy can be type Actor[1..*] and Actors can inherit Element and Element has identifiedBy). This proposal was meant to just cover the identifiers (sorry, I realized the subject should have been identifiers not identities which may be where the confusion arose). createdBy has always been 1..* (it is in SPDX 2.x and always has been in SPDX 3.x), why is this a huge mess? PURL has some of the same issues around the distinction between identifier and locator, for example, the long debate around referencing container artifacts was rooted in this very issue. The decision there was that the identity portion of the PURL was mandatory and there was an optional location portion. Some identifiers contain canonical location, some identifiers contain instance location, some identifiers contain optional location, and some identifiers contain no location at all (Dr. Seuss). In reverse, most locations used to describe software can be considered an identifier, though not the only identifier and often not the canonical identifier. Where this breaks down is if a location can return different content over time which is why you would want to pair it with a hash. ExternalReference was already co-mingling these concepts, how important do we think it is to break this out now given that when you're pulling out identifiers you can already select the ones you want based on their type? Is this a decision we can defer to keep making progress towards publishing? Sent from Outlook<http://aka.ms/weboutlook> ________________________________ From: Brandon Lum <[email protected]> Sent: Tuesday, May 10, 2022 6:54 AM To: David Kemp <[email protected]> Cc: Jeff Schutt (jefschut) <[email protected]>; William Bartholomew (CELA) <[email protected]>; spdx-tech <[email protected]> Subject: [EXTERNAL] Re: [spdx-tech] Simplifying Identities Looks good to me! I second the point on having proper namespaces - i.e. in the cve example, it feels like it could easily be overloaded. It may also provide some context to help in validating provenance at a later point. On Tue, May 10, 2022 at 9:49 AM David Kemp <[email protected]<mailto:[email protected]>> wrote: @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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc3305%23section-2.2&data=05%7C01%7Cwillbar%40microsoft.com%7C9d5a384763034993abcc08da328cae67%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637877877067269563%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xxBQH1wgmE04MYvJjWPF6oFFIUIb%2BqKYBLymuoEF0X0%3D&reserved=0> 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdocs.oasis-open.org%2FspecGuidelines%2Fndr%2FnamingDirectives.html%23note-informationResource&data=05%7C01%7Cwillbar%40microsoft.com%7C9d5a384763034993abcc08da328cae67%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637877877067269563%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1ERmujrtYgjwu5mdRJEagPf8hlCnbZFA%2FX754eWLLAw%3D&reserved=0>). 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.spdx.org%2F&data=05%7C01%7Cwillbar%40microsoft.com%7C9d5a384763034993abcc08da328cae67%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637877877067269563%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yHSzvIOqew0ZjJxxT9Vx%2F5qn%2BTEVme22xCf%2Fs1CbTmM%3D&reserved=0> <[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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.spdx.org%2F&data=05%7C01%7Cwillbar%40microsoft.com%7C9d5a384763034993abcc08da328cae67%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637877877067269563%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yHSzvIOqew0ZjJxxT9Vx%2F5qn%2BTEVme22xCf%2Fs1CbTmM%3D&reserved=0>" <[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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgithub.com%2F&data=05%7C01%7Cwillbar%40microsoft.com%7C9d5a384763034993abcc08da328cae67%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637877877067269563%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4X4BCayxViU%2FXq7nPm1S%2FpleDMHO9AUqT88N%2B44I5zg%3D&reserved=0>", "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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Faka.ms%2Fweboutlook&data=05%7C01%7Cwillbar%40microsoft.com%7C9d5a384763034993abcc08da328cae67%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637877877067269563%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GJxxDEl7YELqf5EAuGMeScd8qKrvfDM8F7b18jBjMXE%3D&reserved=0> -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4501): https://lists.spdx.org/g/Spdx-tech/message/4501 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]] -=-=-=-=-=-=-=-=-=-=-=-
