> 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?
SPDX 2.x does not have Elements, and the "Identities" it uses are actually identifiers. Document Creation Information has a creator: 6.8.3 Examples > EXAMPLE 1 Tag: Creator: Creator: Person: Jane Doe () > Creator: Organization: ExampleCodeInspect () > Creator: Tool: LicenseFind-1.0 and those identifiers are tagged with Person/Org/Tool type. SPDX 2.x does not have a "package metadata creator" field like the 3.0 Element, and the supplier of the package is a single identifier. Cardinality 1..1 7.6.3 Examples > EXAMPLE 1 Tag: PackageOriginator: > PackageOriginator: Organization: ExampleCodeInspect ([email protected]) We have not used 3.0 yet, where every metadata section is an Element and every Element has multiple creators plus perhaps an originator. And modeling identifiers as Identities is the issue under discussion. The "huge mess" is that the act of creation of every element has a creator/actor, and if elements can be "verifiedBy" then verification implies attribution and accountability. If an Element is created by > { > "SPDXID": "urn:github.com:users:iamwillbar", > "type": "Person", > "name": "William Bartholomew", > "identifiedBy": [ > {"type": "EmailAddress", "email": "[email protected]"}, > {"type": "Account", "authority": "github.com", "username": > "iamwillbar"} > ] > } then it cannot also be created by "type": "Organization", "name": "Microsoft". Either you the person created it and you may claim a Microsoft account, or Microsoft the organization created it and has authorized your personal account to act on it's behalf. Every identity that can perform a verifiable action has a credential, and that single credential names a single actor who can have multiple identifiers. How will Elements created and verified using multiple Identity credentials work? Dave On Tue, May 10, 2022 at 10:53 AM William Bartholomew (CELA) < [email protected]> wrote: > 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]> 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]> 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]> 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]> > *Reply-To: *"[email protected]" <[email protected]> > *Date: *Monday, May 9, 2022 at 8:00 PM > *To: *spdx-tech <[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]"}, > > {"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 (#4503): https://lists.spdx.org/g/Spdx-tech/message/4503 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]] -=-=-=-=-=-=-=-=-=-=-=-
