+1 to focus commentary on issues
", "time": "2023-09-25T15:11:18Z"}, {"author": "Orie Steele", "text": "which issue is the dialogue addressing?
", "time": "2023-09-25T15:11:31Z"}, {"author": "Neal McBurnett", "text": "Where is the discussion about company ids being referenced? Email? Slack??
", "time": "2023-09-25T15:11:50Z"}, {"author": "Raymond Lutz", "text": "It would be good to have this issue written up in more detail.
", "time": "2023-09-25T15:11:57Z"}, {"author": "Orie Steele", "text": "Perhaps use this for now: https://github.com/ietf-scitt/draft-birkholz-scitt-scrapi/pull/2
", "time": "2023-09-25T15:12:01Z"}, {"author": "Orie Steele", "text": "Because it does cover feeds.
", "time": "2023-09-25T15:12:17Z"}, {"author": "Orie Steele", "text": "Feed examples here: https://github.com/ietf-scitt/draft-birkholz-scitt-scrapi/pull/2/files#diff-670e12da794e4d369f89879af7d128ce715d9ca83a98b0eefdad1059b7684e7bR13
", "time": "2023-09-25T15:12:43Z"}, {"author": "Steve Lasker", "text": "It's fair that we should ground this in an issue around Feed ID
", "time": "2023-09-25T15:13:13Z"}, {"author": "Steve Lasker", "text": "And, fair we should standardize on the IETF email thread. I'll send the content I posted on Slack to the alias.
", "time": "2023-09-25T15:14:17Z"}, {"author": "Orie Steele", "text": "IETF business happens on mailing lists, but context and other commentary tend to happen wherever people are.
", "time": "2023-09-25T15:14:27Z"}, {"author": "Charles Hart", "text": "Sorry Steve. Mistook who was talking i.e. thought it was Neal.
", "time": "2023-09-25T15:16:39Z"}, {"author": "Raymond Lutz", "text": "I looked at all those links and I don't see a good description of the issue. I agree with Henk that the issuer is in the header and I believe it has to stay there!
", "time": "2023-09-25T15:17:45Z"}, {"author": "Neal McBurnett", "text": "Steve can you give us a link here in the chat?
", "time": "2023-09-25T15:17:50Z"}, {"author": "Orie Steele", "text": "Feeds are resources controlled by a Transparency Service?
", "time": "2023-09-25T15:21:36Z"}, {"author": "Orie Steele", "text": "We should focus on the Job that is solved, by using feeds.
", "time": "2023-09-25T15:22:34Z"}, {"author": "Steve Lasker", "text": "Neal: sorry, which link?
", "time": "2023-09-25T15:23:02Z"}, {"author": "Neal McBurnett", "text": "Steve: Whatever you shared in slack.
", "time": "2023-09-25T15:23:25Z"}, {"author": "Steve Lasker", "text": "ahh, ok
", "time": "2023-09-25T15:23:42Z"}, {"author": "Steve Lasker", "text": "I caught up on: [SCITT] Company Identification thread. It was super insightful to read the various thoughts and perspectives.
\nReading through the thread, are we trying to come up with a well-formed name for the feed-id?
\nOr, should we possibly create a unique ID for the feed-id (GUID) that need not change over time. Then, add name/value pairs with the creation of the feed-id that has all the varying ways someone might find the feed?
\nThe name value pairs could be:
\nfile-hash /
\nversion / semver | calver
\norganization | identity | company / acme (Note: this is NOT the identity, rather a string)
\nplatform
\narchitecture
\nglief-id
\npurl
\ncpe
\nswid
\nThe feed-id creation is itself a signed statement, from an identity.
^ This doesn't format very well.
", "time": "2023-09-25T15:24:25Z"}, {"author": "Orie Steele", "text": "https://datatracker.ietf.org/doc/draft-mcmillion-key-transparency/
", "time": "2023-09-25T15:28:45Z"}, {"author": "Orie Steele", "text": "See \"User Operations\".
", "time": "2023-09-25T15:29:05Z"}, {"author": "Raymond Lutz", "text": "I'm not sure creating a new feed id is valid. Better to just search the data for issuer and product. If product name is the same as feed, then we it is a quagmire to try to constrain that and rather submitters can do so.
", "time": "2023-09-25T15:29:25Z"}, {"author": "Neal McBurnett", "text": "If the stuff that people can search is separate from SCITT and doesn't have the same availability guarantees and append-only nature that SCITT has, that seems to lead to new problems.
", "time": "2023-09-25T15:29:49Z"}, {"author": "Orie Steele", "text": "both issuer and product can be identified many different ways... hence the problem regarding feeds.
", "time": "2023-09-25T15:29:59Z"}, {"author": "Raymond Lutz", "text": "Right orie but \"one level up\" from this api.
", "time": "2023-09-25T15:30:22Z"}, {"author": "Steve Lasker", "text": "Here's the issue we've been riffing on related to the Feed ID:
\nhttps://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/issues/11
issuer and product both have protocol relevant parameters in SCITT envelopes... so its not a layer up... it's an interoperability point.
", "time": "2023-09-25T15:31:53Z"}, {"author": "Steve Lasker", "text": "https://scitt.io/#interacting-with-scitt
", "time": "2023-09-25T15:32:31Z"}, {"author": "Raymond Lutz", "text": "semantic name of the product is the issue I think we are dealing with here. We can specify for sw what that might be but for all supply chains, the factors are unknown. Thus I still submit that the issue can be pushed up a level.
", "time": "2023-09-25T15:38:28Z"}, {"author": "Steve Lasker", "text": "Ray/Charlie: This is one of the things I came away with, after reading the thread: https://mailarchive.ietf.org/arch/msg/scitt/kubTlBU7sKLSkTpHdVqudsY7U1Y/
\nFeed IDs were being combined with a recognizable human readable string identifier, and the company name/id was also being \"embedded\" in the string.
What I came away with, was should the Feed ID just be another statement, with an attached identity.
", "time": "2023-09-25T15:40:29Z"}, {"author": "Raymond Lutz", "text": "Maybe there is a way to make a url from the header information to allow it to be conveniently searched. I would hope we could decide on a strict mapping scheme that contains issuer id and product id.
", "time": "2023-09-25T15:50:55Z"}, {"author": "Raymond Lutz", "text": "But then other than that, we don't need to know anything more about it.
", "time": "2023-09-25T15:51:22Z"}, {"author": "Steve Lasker", "text": "Neal: I hear your comment about \"company\" and I agree. Company is too formal. An independent user is just as interesting. A consumer can choose who they wish to trust.
", "time": "2023-09-25T15:51:50Z"}, {"author": "Steve Lasker", "text": "We need a more generic <name> to represent humans, collections of humans, projects and \"companies\"
", "time": "2023-09-25T15:52:14Z"}, {"author": "Raymond Lutz", "text": "But then the product ID and version would need to be separate fields so the \"feed\" would automatically search over all versions. I argue that that this can be considered one level up.
", "time": "2023-09-25T15:54:10Z"}, {"author": "Steve Lasker", "text": "https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/pull/94
", "time": "2023-09-25T15:54:46Z"}, {"author": "Neal McBurnett", "text": "Dick: re flexibility of identifiers. Thanks. But the ability for anyone to probe an email address and maybe get a bounce (which may itself depend on who is probing, and when and how) isn't much of a \"verification\". So I think the requirements are more around continuity than verification
", "time": "2023-09-25T15:57:14Z"}, {"author": "Raymond Lutz", "text": "Could the feed id be included in the header, similar to a DID URL.
", "time": "2023-09-25T15:58:16Z"}, {"author": "Orie Steele", "text": "https://ts.example/issuer/did:web:example.com/feeds/products/....
", "time": "2023-09-25T15:59:41Z"}, {"author": "Henk Birkholz", "text": "gotta drop. Thu is now a feeds work day for me
", "time": "2023-09-25T15:59:50Z"}, {"author": "Steve Lasker", "text": "Emails, domans (dns) all can change ownership over time. This was well covered in the thread.
\nThe thing SCITT can help with is it provides time as the context. On 9/25/2023 @ 8:59 UTC, company Foo made a statement.