Agenda: https://datatracker.ietf.org/doc/agenda-115-scitt/
", "time": "2022-11-10T09:32:12Z"}, {"author": "Olle Johansson", "text": "Materials for the meeting: https://datatracker.ietf.org/meeting/115/session/scitt
", "time": "2022-11-10T09:32:33Z"}, {"author": "Muhammad Sardar", "text": "Please move camera to speaker
", "time": "2022-11-10T09:33:43Z"}, {"author": "Christopher Inacio", "text": "@Meetecho Robot can you adjust the camera to the speaker
", "time": "2022-11-10T09:43:06Z"}, {"author": "Lorenzo Miniero", "text": "It looks like we're framing the speaker already?
", "time": "2022-11-10T09:43:48Z"}, {"author": "Christopher Inacio", "text": "Sorry, I was just echoing a statement that didn't call out the meetecho robot; thanks for checking.
", "time": "2022-11-10T09:44:31Z"}, {"author": "Lorenzo Miniero", "text": "No problem, thanks!
", "time": "2022-11-10T09:45:04Z"}, {"author": "Olle Johansson", "text": "Antoine Delignat-Lavaud speaking about SCITT architecture
", "time": "2022-11-10T09:48:05Z"}, {"author": "Ned Smith", "text": "Both flows would be called reference values or endorsements using RATS terminology
", "time": "2022-11-10T09:55:44Z"}, {"author": "Dave Thaler", "text": "It's ok (but not ideal) if scitt uses a different definition from rats as long as it's internally consistent. But it would be inconsistent to say that there's a verifier that doesn't verify, but a registry that verifies (which is what the slide implies)
", "time": "2022-11-10T09:57:59Z"}, {"author": "Steve Lasker", "text": "Regarding name changes: Converge Claim and Statement #34: https://github.com/ietf-scitt/draft-birkholz-scitt-architecture/issues/34
", "time": "2022-11-10T09:58:33Z"}, {"author": "Dave Thaler", "text": "to me, it seems that the registry is the rats verifier, and the (misnamed) \"verifier\" here is the relying party
", "time": "2022-11-10T09:58:53Z"}, {"author": "Steve Lasker", "text": "We want to support RATS terminology and clarify terminology that represents different things
", "time": "2022-11-10T09:59:14Z"}, {"author": "Dave Thaler", "text": "but I can't tell for sure
", "time": "2022-11-10T09:59:24Z"}, {"author": "Olle Johansson", "text": "I believe what Elliot is proposing is what Sigstore is doing
", "time": "2022-11-10T10:00:15Z"}, {"author": "Ned Smith", "text": "@elliot passport model?
", "time": "2022-11-10T10:00:32Z"}, {"author": "Ned Smith", "text": "@eliot passport model?
", "time": "2022-11-10T10:00:55Z"}, {"author": "Steve Lasker", "text": "@Dave Thaler , think of SCITT as a means to store \"claims\", likely renamed to \"signed statements\", where the issuers (identity of the statement) has been verified by the eNotary. The SCITT service doesn't weigh into the validity of the statement, but rather the validity of the issuer to make the statement.
", "time": "2022-11-10T10:04:29Z"}, {"author": "Olle Johansson", "text": "I think it's important that we find a distributed model for registry/notary service. A question should be \"how does the verifier find the registry for XXXX\" ?
", "time": "2022-11-10T10:05:16Z"}, {"author": "Steve Lasker", "text": "The information for where the statement was persisted is stored in the receipt. Antoine is getting to it :)
", "time": "2022-11-10T10:06:45Z"}, {"author": "Ned Smith", "text": "\"ledger\" implies durability
", "time": "2022-11-10T10:06:56Z"}, {"author": "Henk Birkholz", "text": "+1 Ned
", "time": "2022-11-10T10:07:39Z"}, {"author": "Ned Smith", "text": "I don't like using \"evidence\" terminlogy in this context
", "time": "2022-11-10T10:08:43Z"}, {"author": "Olle Johansson", "text": "The \"feed\" needs to be better specified. Maybe https://github.com/package-url/purl-spec
", "time": "2022-11-10T10:08:59Z"}, {"author": "Dave Thaler", "text": "@Steve Lasker thanks for the explanation. I would say the text on the slide should be corrected then as that's not how I read the slide.
", "time": "2022-11-10T10:09:36Z"}, {"author": "Henk Birkholz", "text": "Purl is one way, packet URLs are another, even mud URLs would work here
", "time": "2022-11-10T10:09:44Z"}, {"author": "Dave Thaler", "text": "(the slide said the registry verifies the information from the issuer, you're saying it verifies the information about the issuer)
", "time": "2022-11-10T10:10:19Z"}, {"author": "Ned Smith", "text": "+1 regarding 'feed' terminology
", "time": "2022-11-10T10:10:45Z"}, {"author": "Steve Lasker", "text": "Ned Smith said:
\n\n\nI don't like using \"evidence\" terminlogy in this context
\n
@Olle Johansson this is another terminology question. Evidence was thought to be the supporting information. But, we really want to align with known terms. This is why we're currently thinking statement, signed statement, transparent statement represents the payload with headers
", "time": "2022-11-10T10:10:48Z"}, {"author": "Henk Birkholz", "text": "from vs. about. Understood
", "time": "2022-11-10T10:11:03Z"}, {"author": "Henk Birkholz", "text": "+1 Steve
", "time": "2022-11-10T10:11:35Z"}, {"author": "Steve Lasker", "text": "Dave Thaler said:
\n\n\nSteve Lasker thanks for the explanation. I would say the text on the slide should be corrected then as that's not how I read the slide.
\n
Yes, we debated what to change the days before the session, or use the current terminology in the ID. Please express your thoughts at https://github.com/ietf-scitt/draft-birkholz-scitt-architecture/issues/34
", "time": "2022-11-10T10:12:13Z"}, {"author": "Ned Smith", "text": "Is 'transparent xlaim' the same as eviidence?
", "time": "2022-11-10T10:12:33Z"}, {"author": "Ned Smith", "text": "'claim'
", "time": "2022-11-10T10:12:47Z"}, {"author": "Henk Birkholz", "text": "Transparent Claims are the closet equivalent to Evidence
", "time": "2022-11-10T10:13:32Z"}, {"author": "Steve Lasker", "text": "Ned Smith said:
\n\n\nIs 'transparent xlaim' the same as eviidence?
\n
The payload that is being created is a \"statement\", The issuer of the payload signs the payload, which becomes a signed statement. Once the signed statement is posted to the registry (transparency service), the eNotary verifies the issuer identity, type and other policy info, then counter signs the payload with the eNotary signature, issuing a receipt.
\nAs you can see, \"naming is hard\", and we're working to clarify the names to avoid conflict and align with understood terms
Especially, if the registry is verified using rats and a receipt would include an attestation result
", "time": "2022-11-10T10:14:27Z"}, {"author": "Olle Johansson", "text": "How can consumers \"pick a trusted notary\"? Is replication between notaries involved?
", "time": "2022-11-10T10:14:37Z"}, {"author": "Henk Birkholz", "text": "But we are not there yet
", "time": "2022-11-10T10:14:39Z"}, {"author": "Ned Smith", "text": "there may be a directory of eNotery - don't want to be confused if we call notary and directory 'registries'
", "time": "2022-11-10T10:16:38Z"}, {"author": "Steve Lasker", "text": "Olle Johansson said:
\n\n\nHow can consumers \"pick a trusted notary\"? Is replication between notaries involved?
\n
Replicatoin, federation, selected promotion is a great topic. Personally, I think of it similar to any supply chain. I don't bring home everything from my local grocery store, or everything from Tesco
\nI do bring in information related to the specific content I need.
\nThe eNotary simply veifies the issuer was valid. It's not an opinion of quality of the statement.
\nBut, you can have statements from others that do issue qualificatoins of quality, where the eNotary will assure their identity is valid. So, to your question of trusted notary, you're really asking do you trust the issuers, and the eNotary is just making sure the issuer is really who they say they are.
How do we make sure that registries doesn't manipulate data - remove receipts, allow modification of them etc
", "time": "2022-11-10T10:19:44Z"}, {"author": "Joshua Lock", "text": "the submission is signed by the submitter
\n\n", "time": "2022-11-10T10:21:08Z"}, {"author": "Olle Johansson", "text": "Some sophisticated consumers may additionally check details of the claim, re-verify the issuer\u2019s signature, or apply additional policies before they accept the artifact
\n
For an Open Source project, almost anyone can be \"issuer\" - how does a verifier find out what claim to use?
", "time": "2022-11-10T10:21:15Z"}, {"author": "Steve Lasker", "text": "Olle Johansson said:
\n\n\nHow do we make sure that registries doesn't manipulate data - remove receipts, allow modification of them etc
\n
Great question. Each \"statement\" is independent. A statement may reference other statements in its payload. Orie/Henk will talk more about this in the hackathon report.
\nThe Registry has a signature to assure its not tampered with.
Olle Johansson said:
\n\n\nFor an Open Source project, almost anyone can be \"issuer\" - how does a verifier find out what claim to use?
\n
Awesome. Just as humans choose who they trust, so does a SCITT consumer, through policy. There's a secure by default policy, with an opt into whom you trust.
\nYou can choose to trust everyone, but that's a choice.
So it's \"consistent\" not \"correct\"
", "time": "2022-11-10T10:22:48Z"}, {"author": "Jim Reid", "text": "+1 Brendan
", "time": "2022-11-10T10:23:19Z"}, {"author": "Massimiliano Pala", "text": "Can claim be \"reovked\" ? or are issuer's identities \"revoked\" if found to be malicious or inconsistent?
", "time": "2022-11-10T10:23:44Z"}, {"author": "Christopher Inacio", "text": "+1 Brendan
", "time": "2022-11-10T10:24:02Z"}, {"author": "Steve Lasker", "text": "Do you \"trust\" every website that happens to have a cert with an HTTPS endpoint? Or, do you wish to selectively trust which you allow in your environment?
", "time": "2022-11-10T10:24:15Z"}, {"author": "Ned Smith", "text": "What determines inconsistent statements - is this the role of a consensus algorithm?
", "time": "2022-11-10T10:24:21Z"}, {"author": "Christopher Inacio", "text": "And especially with DIDs - the identity could be especially weak
", "time": "2022-11-10T10:24:36Z"}, {"author": "Olle Johansson", "text": "@Steve Lasker It's basically the same problem as we have with Docker registry... But a reason why I want the \"feed\" to be a bit more strict than presented so far. There may be more slides coming though...
", "time": "2022-11-10T10:24:45Z"}, {"author": "Steve Lasker", "text": "Massimiliano Pala said:
\n\n\nCan claim be \"reovked\" ? or are issuer's identities \"revoked\" if found to be malicious or inconsistent?
\n
Yes, we'll have more info on this coming. We didn't have enough info written up for 115
", "time": "2022-11-10T10:24:47Z"}, {"author": "Massimiliano Pala", "text": "Thanks!
", "time": "2022-11-10T10:25:06Z"}, {"author": "Joshua Lock", "text": "Olle Johansson said:
\n\n\nFor an Open Source project, almost anyone can be \"issuer\" - how does a verifier find out what claim to use?
\n
yes, this is an excellent question that others (i.e, Sigstore) are also trying to figure out. Sigstore afaik is currently favouring having the software repositories (i.e., npm) map identity->project (id's Alice, eve, bob can sign for project foobar)
", "time": "2022-11-10T10:25:18Z"}, {"author": "Christopher Inacio", "text": "Steve Lasker said:
\n\n\nDo you \"trust\" every website that happens to have a cert with an HTTPS endpoint? Or, do you wish to selectively trust which you allow in your environment?
\n
that's a false equivalence though, right? It might be true if I expect to be running an application in my browser and saving my data via that tool, but not if I'm just reading some bit of text.
", "time": "2022-11-10T10:26:12Z"}, {"author": "Brendan Moran", "text": "Steve Lasker said:
\n\n\nDo you \"trust\" every website that happens to have a cert with an HTTPS endpoint? Or, do you wish to selectively trust which you allow in your environment?
\n
To be honest, I'm not convinced by that model. I don't want to trust a server, I want to trust a document signer. The fact that there is online-signing--implying online signing keys--is an artefact of TLS. I'm not convinced that identity verification should be conflated with content authenticity. But HTTPS is what we have, and most people appear to think it's good enough.
", "time": "2022-11-10T10:26:30Z"}, {"author": "Steve Lasker", "text": "Olle Johansson said:
\n\n\nSteve Lasker It's basically the same problem as we have with Docker registry... But a reason why I want the \"feed\" to be a bit more strict than presented so far. There may be more slides coming though...
\n
Yeah, great point. Docker Hub essentially has three cateogires:
\nYou don't, and shouldn't trust everything that's in Docker Hub, or every \"offiical vendor\"
", "time": "2022-11-10T10:26:48Z"}, {"author": "Ned Smith", "text": "dumb question - how do I quote someone in the chat?
", "time": "2022-11-10T10:27:34Z"}, {"author": "Jim Reid", "text": "\"good enough\" for HTTPS is unlikely to be good enough for transferring assets.
", "time": "2022-11-10T10:27:37Z"}, {"author": "Olle Johansson", "text": "@Steve Lasker Yes, it's a docker-controlled-authorization process that doesn't really scale... I am not saying the current tradition in OpenSource with GPG keys work either... Work is needed here.
", "time": "2022-11-10T10:27:53Z"}, {"author": "Jim Reid", "text": "@Ned, you can't. Unless you C&P their text.
", "time": "2022-11-10T10:28:12Z"}, {"author": "Massimiliano Pala", "text": "Well, we have already many repositories of open-source software... maybe those can be already used as the basis for notaries databases where the notaries link existing repos/packages/etc. with the metadata...
", "time": "2022-11-10T10:28:21Z"}, {"author": "Olle Johansson", "text": "Ned Smith said:
\n\n\ndumb question - how do I quote someone in the chat?
\n
In the Zulip client you have a small menu with three dots coming up when hovering over a message
", "time": "2022-11-10T10:28:28Z"}, {"author": "Joshua Lock", "text": "Ned Smith said:
\n\n\ndumb question - how do I quote someone in the chat?
\n
Hover over message, click 3 dots (message actions), select quote and reply or forward
", "time": "2022-11-10T10:28:47Z"}, {"author": "Brendan Moran", "text": "@Ned Smith You can quote in zulip by hovering over the message, then clicking the triple-dot in the right hand corner. [edit]: I got scooped
", "time": "2022-11-10T10:28:55Z"}, {"author": "Kathleen Moriarty", "text": "Many customers, likely most, will need these software decisions to be made for them as they will not have the resources to do it themselves. Transparency to allow both those with and without resources to make the decisions or audit the process and decisions has to be part of the customer requirements or this will only work for a few organizations.
", "time": "2022-11-10T10:30:18Z"}, {"author": "Kathleen Moriarty", "text": "I'll read the drafts and comment on list.
", "time": "2022-11-10T10:30:28Z"}, {"author": "Brendan Moran", "text": "@Ned Smith I completely agree that HTTPS isn't enough. But how do we make that change?
", "time": "2022-11-10T10:30:29Z"}, {"author": "Olle Johansson", "text": "Maik Reichert going to speak about SCITT Receipts
", "time": "2022-11-10T10:31:36Z"}, {"author": "Ned Smith", "text": "There is a secure asset transfer BOF later today
", "time": "2022-11-10T10:31:40Z"}, {"author": "Steve Lasker", "text": "Kathleen Moriarty said:
\n\n\nMany customers, likely most, will need these software decisions to be made for them as they will not have the resources to do it themselves. Transparency to allow both those with and without resources to make the decisions or audit the process and decisions has to be part of the customer requirements or this will only work for a few organizations.
\n
Yes, absolutely. An entity can choose to trust another entity that accounts for a vertiical or collection.
", "time": "2022-11-10T10:31:54Z"}, {"author": "Brendan Moran", "text": "@Ned Smith Thanks for pointing that out!
", "time": "2022-11-10T10:32:43Z"}, {"author": "Olle Johansson", "text": "Kathleen Moriarty said:
\n\n\nMany customers, likely most, will need these software decisions to be made for them as they will not have the resources to do it themselves. Transparency to allow both those with and without resources to make the decisions or audit the process and decisions has to be part of the customer requirements or this will only work for a few organizations.
\n
Yes, for a majority it will just be a red light/green light automated process. We need to make that possible for the majority of the cases.
", "time": "2022-11-10T10:32:54Z"}, {"author": "Dave Thaler", "text": "What does \"verification of the claim\" mean here, not that the information is correct just that it came from a trusted issuer?
", "time": "2022-11-10T10:32:56Z"}, {"author": "Massimiliano Pala", "text": "The main concern with the architecture is that it seems to be skewed towards corporate environment/use where it is easier to force trust in a verifier. Deciding to trust a verier or another might be difficult for individuals.
", "time": "2022-11-10T10:33:09Z"}, {"author": "Dave Thaler", "text": "or that the claim value matches your policy of what is acceptable?
", "time": "2022-11-10T10:33:37Z"}, {"author": "Brendan Moran", "text": "Massimiliano Pala said:
\n\n\nThe main concern with the architecture is that it seems to be skewed towards corporate environment/use where it is easier to force trust in a verifier. Deciding to trust a verier or another might be difficult for individuals.
\n
Using consensus/popularity might be worthwhile, but it's vulnerable to astroturfing. A CA model might also be interesting.
", "time": "2022-11-10T10:34:44Z"}, {"author": "Steve Lasker", "text": "Dave Thaler said:
\n\n\nor that the claim value matches your policy of what is acceptable?
\n
Maik is explaining it now. A particular Notary may only sign real estate contracts. If you submitted a court document to be notarized, it would reject it.
\nSo, the policy just says this notary notarized the statement to say it verified the issuer.
Massimiliano Pala said:
\n\n\nThe main concern with the architecture is that it seems to be skewed towards corporate environment/use where it is easier to force trust in a verifier. Deciding to trust a verier or another might be difficult for individuals.
\n
Great point. Think of the apple store as a means to assure it's consumers have valid content.
", "time": "2022-11-10T10:36:16Z"}, {"author": "Olle Johansson", "text": "I assumed that the notary also adds a signed timestamp
", "time": "2022-11-10T10:36:19Z"}, {"author": "Steve Lasker", "text": "The receipt provides for offline verification so you're not required to query the scitt ledger.
", "time": "2022-11-10T10:38:47Z"}, {"author": "Dave Thaler", "text": "@Steve Lasker I dont think that answers my question. I'm asking what \"Receipt enables offline verification of the claim\" means. That it came from a trusted issuer? That it came from a trusted notary? That the information in the claim is truthful? Something else?
", "time": "2022-11-10T10:41:13Z"}, {"author": "Brendan Moran", "text": "Do you need a COSE message type? Or is a CBOR Tag registration enough?
", "time": "2022-11-10T10:41:51Z"}, {"author": "Olle Johansson", "text": "Next up: Hackathon report with Henk Birkholz and Orie Steele
", "time": "2022-11-10T10:42:27Z"}, {"author": "Joshua Lock", "text": "@Dave Thaler aiui the receipt tells you that the the eNotary believes the issuer/signer is authorised to make claims about the subject
\n(I probably have all the SCITT terms wrong)
Hackathon without any CODE? Arrrrggghhhh
", "time": "2022-11-10T10:44:35Z"}, {"author": "Steve Lasker", "text": "Joshua Lock said:
\n\n\nDave Thaler ...(I probably have all the SCITT terms wrong)
\n
Naming is hard. I think we're getting clear on what each \"thing\" is, we just need to identify names that don't mean something else to other experts working in similar spaces. All input on where we can align a definition with an existing term, or where we should use a different term to avoid confusion
", "time": "2022-11-10T10:47:09Z"}, {"author": "Dave Thaler", "text": "checking the arch draft, I think the answer is that verification means checking that the issuer is consistent and non-equivocal when making claims, and inspecting their Statements
", "time": "2022-11-10T10:47:56Z"}, {"author": "Dave Thaler", "text": "(I still find the \"inspecting their Statements\" phrase confusing though as I can't find a definition of that in the draft)
", "time": "2022-11-10T10:49:42Z"}, {"author": "Brendan Moran", "text": "As far as detachable signatures and hash-based references go, SUIT has been iterating on this concept for a very long time.
", "time": "2022-11-10T10:49:44Z"}, {"author": "Brendan Moran", "text": "Also, there's RFC6920, naming things with hashes. https://www.rfc-editor.org/rfc/rfc6920.html
", "time": "2022-11-10T10:51:01Z"}, {"author": "Dave Thaler", "text": "e.g., does \"inspecting their Statements\" mean applying an appraisal policy to compare the Statement against acceptable state and making a decision based on that comparison? (which would be consistent with \"Verifier\" in rats)
", "time": "2022-11-10T10:51:46Z"}, {"author": "Ned Smith", "text": "someone said the notary could be a DLT. A DLT consensus algorithm establishes consistency of a thing. There has been discussion about consistency. It would be helpful if the arch relies on a consensus algorithm or if that is 'trusted' when selecting a particular notary
", "time": "2022-11-10T10:53:15Z"}, {"author": "Brendan Moran", "text": "Dave Thaler said:
\n\n\ne.g., does \"inspecting their Statements\" mean applying an appraisal policy to compare the Statement against acceptable state and making a decision based on that comparison? (which would be consistent with \"Verifier\" in rats)
\n
Earlier presentations implied that this was configurable. From the presentations, I get the impression that a SCITT notary applies a policy verification engine that includes a single default policy--signature must be valid--but more can be added, depending on use-case.
", "time": "2022-11-10T10:54:36Z"}, {"author": "Steve Lasker", "text": "Ned Smith said:
\n\n\nsomeone said the notary could be a DLT. A DLT consensus algorithm establishes consistency of a thing. There has been discussion about consistency. It would be helpful if the arch relies on a consensus algorithm or if that is 'trusted' when selecting a particular notary
\n
I think you're asking for consensus across various issuers of a statement. The eNotary just affirms the issuer is who they claim to be.
\nIf you argue a contract in court, you can start with the belief the parties are who they claim to be, as the contract was notarized saying the signing parties are who they claim to be
Dave Thaler said:
\n\n\ne.g., does \"inspecting their Statements\" mean applying an appraisal policy to compare the Statement against acceptable state and making a decision based on that comparison? (which would be consistent with \"Verifier\" in rats)
\n
appraisal to a verifier requires attestation evidence. I don't see an equivalence in scitt
", "time": "2022-11-10T10:55:59Z"}, {"author": "Jon Geater", "text": "It's explicit in the documents that the only thing the Notary Service must do is verify the identity of the entity making the claim. Everything else is an applicaiton-level value-add
", "time": "2022-11-10T10:56:19Z"}, {"author": "Jon Geater", "text": "Of course this is our first meeting so there's time for feedback on that point
", "time": "2022-11-10T10:56:53Z"}, {"author": "Brendan Moran", "text": "@Jon Geater That's what I thought. Thanks for confirming.
", "time": "2022-11-10T10:57:03Z"}, {"author": "Christopher Inacio", "text": "I think the discussion here has focused on open registries but I believe everything must also must support closed or centralized registry operations in the semantics too. For example, with the new US Executive Order, it would seem likely that US Gov Services Administration (GSA) would run a centralized registry for all other US Gov looks at trust in software.
", "time": "2022-11-10T10:57:18Z"}, {"author": "Ned Smith", "text": "Orie is using 'validation' instead of appraisal
", "time": "2022-11-10T10:57:35Z"}, {"author": "Steve Lasker", "text": "Policy: there is policy on ingress: (registration policy). The extensibility of it isn't likely limited in the Specifications, rather the ability to apply policy is defined.
", "time": "2022-11-10T10:57:51Z"}, {"author": "Christopher Inacio", "text": "I can imagine other governments, or industry verticals having similar approaches. Whereas, open source or smaller devices / consumer goods would get vastly more complicated.
", "time": "2022-11-10T10:58:33Z"}, {"author": "Brendan Moran", "text": "I think this is a good application of RFC6920. It would provide a good way to identify transparent claims on a particular registry.
", "time": "2022-11-10T10:58:39Z"}, {"author": "Ned Smith", "text": "is a transparency service a notery?
", "time": "2022-11-10T10:59:12Z"}, {"author": "Ned Smith", "text": "every speaker seems to use different terminology?
", "time": "2022-11-10T10:59:38Z"}, {"author": "Henk Birkholz", "text": "Notary + api
", "time": "2022-11-10T10:59:39Z"}, {"author": "Steve Lasker", "text": "Ned Smith said:
\n\n\nis a transparency service a notery?
\n
A transparency service HAS an eNotary. The eNotary verifies the identity, before anything is placed on the ledger
", "time": "2022-11-10T10:59:53Z"}, {"author": "Henk Birkholz", "text": "Ned, that is the exact first thing we have to clear out. Starting.... now!
", "time": "2022-11-10T11:00:27Z"}, {"author": "Jon Geater", "text": "To help concentrate the discussions and prioritise effort here, the SCITT about page has the group milestones on: there are a couple of things for December this year (including terminology) and then targeting March '23 for the next stage with interaction models and such.
\nhttps://datatracker.ietf.org/wg/scitt/about/
", "time": "2022-11-10T11:00:56Z"}, {"author": "Dave Thaler", "text": "Brendan Moran said:
\n\n\nDave Thaler said:
\n\n\ne.g., does \"inspecting their Statements\" mean applying an appraisal policy to compare the Statement against acceptable state and making a decision based on that comparison? (which would be consistent with \"Verifier\" in rats)
\nEarlier presentations implied that this was configurable. From the presentations, I get the impression that a SCITT notary applies a policy verification engine that includes a single default policy--signature must be valid--but more can be added, depending on use-case.
\n
But \"inspecting their Statements\" is in the context of the Verifier not the notary, so what the notary does is mostly irrelevant to the verification text.
", "time": "2022-11-10T11:02:18Z"}, {"author": "Steve Lasker", "text": "Dave Thaler said:
\n\n\nBut \"inspecting their Statements\" is in the context of the Verifier not the notary, so what the notary does is mostly irrelevant to the verification text.
\n
Can you evaluate a statement if you don't trust the issuer is real?
", "time": "2022-11-10T11:03:09Z"}, {"author": "Dave Thaler", "text": "Ned Smith said:
\n\n\nDave Thaler said:
\n\n\ne.g., does \"inspecting their Statements\" mean applying an appraisal policy to compare the Statement against acceptable state and making a decision based on that comparison? (which would be consistent with \"Verifier\" in rats)
\nappraisal to a verifier requires attestation evidence. I don't see an equivalence in scitt
\n
For the scitt definition of appraisal and verifier and evidence it is equivalent as far as I can tell. You can't tell whether the claims are truthful without attestation, but scitt as far as I can tell treats truthfulness as out of scope, i.e., you need to use scitt + attestation to tell whether something is actually truthful.
", "time": "2022-11-10T11:04:22Z"}, {"author": "Dave Thaler", "text": "Steve Lasker said:
\n\n\nDave Thaler said:
\n\n\nBut \"inspecting their Statements\" is in the context of the Verifier not the notary, so what the notary does is mostly irrelevant to the verification text.
\nCan you evaluate a statement if you don't trust the issuer is real?
\n
Probably not, but the text implies you first check the issuer, and once you trust it's real then you \"inspect their Statements\" but i can't find what \"inspect their Statements\" means, I can only guess as mentioned above
", "time": "2022-11-10T11:05:30Z"}, {"author": "Steve Lasker", "text": "The notarization provides that confidence to move forward. You don't have to include all statements from issuers you choose to not trust, or choose not to trust for a particular scenario.
\n\n\nbut i can't find what \"inspect their Statements\" means, I can only guess as mentioned above
\n
At this point, verifying the contents of the statement is out of scope of SCITT. This is where we look to enable and integrate with other validation systems.
", "time": "2022-11-10T11:06:53Z"}, {"author": "Dave Thaler", "text": "providing \"confidence\" is subjective. If you choose to implicitly trust the issuer to not lie, you might have confidence. If you have a zero-trust policy then it would not provide confidence without attestation or some other way to verify truth of the claim.
", "time": "2022-11-10T11:08:27Z"}, {"author": "Ned Smith", "text": "if claim3 didn't add new statements, would the combination of claim1 and claim2 be a claim - namely claim3
", "time": "2022-11-10T11:08:56Z"}, {"author": "Steve Lasker", "text": "Ned Smith said:
\n\n\nif claim3 didn't add new statements, would the combination of claim1 and claim2 be a claim - namely claim3
\n
The concept of \"endorsement\", where another issuer makes a statement, based on many claims is something we're considering.
", "time": "2022-11-10T11:09:49Z"}, {"author": "Dave Thaler", "text": "e.g., \"software with digest X includes static libary Y version Z\". You have to either implicitly trust the issuer to not lie, or you have to have a way to verify that is indeed the case.
", "time": "2022-11-10T11:09:51Z"}, {"author": "Dave Thaler", "text": "similarly \"the cloud service you're talking to is running OS version X\"... you have to either trust the cloud servi e to not lie, or if you have a zero-trust policy then you need attestation (in the rats sense) to verify that what is running there is actually OS version X.
", "time": "2022-11-10T11:11:33Z"}, {"author": "Ned Smith", "text": "Steve Lasker said:
\n\n\nNed Smith said:
\n\n\nif claim3 didn't add new statements, would the combination of claim1 and claim2 be a claim - namely claim3
\nThe concept of \"endorsement\", where another issuer makes a statement, based on many claims is something we're considering.
\n
endorsement is a claim that the verifier accepts based on trust in the endorser. by this def'n the transparency service could be a RATS endorser
", "time": "2022-11-10T11:11:39Z"}, {"author": "Steve Lasker", "text": "Having folks engaged across RATS, SUIT and SCITT has been helping assure we resolve conflicting terminology, and built collaborative specs to enable an ecosystem where they are used together
", "time": "2022-11-10T11:13:05Z"}, {"author": "Joshua Lock", "text": "Dave Thaler said:
\n\n\ne.g., \"software with digest X includes static libary Y version Z\". You have to either implicitly trust the issuer to not lie, or you have to have a way to verify that is indeed the case.
\n
or you are comfortable having a non-repudiable claim that you can point to if the issuer does lie
", "time": "2022-11-10T11:14:13Z"}, {"author": "Dave Thaler", "text": "@Joshua Lock if there's no way anyone can tell if the issuer does lie, then having a non-repudiable claim doesn't really help, you still have to implicitly trust the issuer to not lie
", "time": "2022-11-10T11:16:08Z"}, {"author": "Brendan Moran", "text": "Dave Thaler said:
\n\n\nJoshua Lock if there's no way anyone can tell if the issuer does lie, then having a non-repudiable claim doesn't really help, you still have to implicitly trust the issuer to not lie
\n
There's plenty of ways to tell; just not automated ones.
", "time": "2022-11-10T11:16:32Z"}, {"author": "Brendan Moran", "text": "It's been mentioned a few times, but the point here is accountability. Not prevention, necessarily, but after-incident accountability.
", "time": "2022-11-10T11:17:18Z"}, {"author": "Steve Lasker", "text": "While some \"issuers\" do/will lie. If that's intentional, you should likely distrust that issuer.
\nThe reality is most things aren't lies, rather mistakes. Either a mistake the issuer made, and then fixes because you trust that issuer to remediate the mistakes they make. Or, they produced an artifact that surfaced issues with its dependencies. At the time, the dependencies were \"ok\". Later we find there were underlying issues. Can you come back and get updates (refreshed statements).
example?
", "time": "2022-11-10T11:17:20Z"}, {"author": "Dave Thaler", "text": "@Brendan Moran example?
", "time": "2022-11-10T11:17:32Z"}, {"author": "Brendan Moran", "text": "@Dave Thaler Reverse engineer the artefact
", "time": "2022-11-10T11:17:48Z"}, {"author": "Olle Johansson", "text": "I've registred the site \"scittissuerratings.com\" now.
", "time": "2022-11-10T11:17:58Z"}, {"author": "Ned Smith", "text": "Brendan Moran said:
\n\n\nDave Thaler said:
\n\n\nJoshua Lock if there's no way anyone can tell if the issuer does lie, then having a non-repudiable claim doesn't really help, you still have to implicitly trust the issuer to not lie
\nThere's plenty of ways to tell; just not automated ones.
\n
is inconsistency - one transparency svc sees a claim that contradicts a claim seen by a second transparency svc - the same as an issuer lie?
", "time": "2022-11-10T11:19:38Z"}, {"author": "Dave Thaler", "text": "@Brendan Moran fair, but that assumes two things: (1) you actually have the artifact (e.g., it's not a receipt about what's running in a peer you're talking to), and (2) that truth can actually be determined from the artifact itself... e.g., the \"author\" usually cannot be determined from the binary, just to use the example of \"which developer authored the code\" that was asked at the mic earlier
", "time": "2022-11-10T11:20:03Z"}, {"author": "Brendan Moran", "text": "@Ned Smith Sure looks that way, but maybe there are mitigating circumstances?
", "time": "2022-11-10T11:20:11Z"}, {"author": "Steve Lasker", "text": "\n\none transparency svc sees a claim that contradicts a claim seen by a second transparency svc - the same as an issuer lie?
\n
That's a perfect example. Whom do you trust? They may not be \"liers\", but not be trusted for a particular domain.
\nDo you trust a gaming auditor to make claims for finanical software?
The conflict can also be time based.
\nOn Jan 1st the software was fine, by all known info
\nOn Feb 1st, new info was found to say the artifact is problematic. It may be first disclosed (stated) by another ~entity~ (issuers) you trust.
@Dave Thaler So my take is that RATS is about prevention. The attestation side provides proof; at a point in time; that a piece of software running in an environment matches a hash, and that is trustworthy insomuch as that hardware is trustworthy (appraised by the verifier).
\nSCITT is the other end of the problem: Something has already gone wrong. You want to know why. having evidence that an issuer lied (post-facto proof that claim is incorrect) then you can ascribe blame, in a legal sense, to that issuer. That's just as important, IMO, as prevention.
", "time": "2022-11-10T11:22:25Z"}, {"author": "Kathleen Moriarty", "text": "Bredan - I see SCITT as prevention as well, even though it can help with the use case of things went wrong. If it were to provide an allowlist of software, that's prevention. Anything unexpected would not be permitted.
", "time": "2022-11-10T11:24:13Z"}, {"author": "Brendan Moran", "text": "Dave Thaler said:
\n\n\ne.g., the \"author\" usually cannot be determined from the binary, just to use the example of \"which developer authored the code\" that was asked at the mic earlier
\n
FWIW, that's some OSINT that I don't think you want in the public. It gives a social engineer a list of targets.
", "time": "2022-11-10T11:24:14Z"}, {"author": "Brendan Moran", "text": "Good point @Kathleen Moriarty
", "time": "2022-11-10T11:25:39Z"}, {"author": "Dave Thaler", "text": "Kathleen Moriarty said:
\n\n\nBredan - I see SCITT as prevention as well, even though it can help with the use case of things went wrong. If it were to provide an allowlist of software, that's prevention. Anything unexpected would not be permitted.
\n
That depends on what you use SCITT for. If you use it for deciding whether to locally install an artifact, then sure, but only if there's no lies in the claim. If there's lies then it doesn't do prevention, only accountability afterwards as Brendan said.
", "time": "2022-11-10T11:26:52Z"}, {"author": "Kathleen Moriarty", "text": "\"as well\"
", "time": "2022-11-10T11:27:59Z"}, {"author": "Ned Smith", "text": "Dave Thaler said:
\n\n\nKathleen Moriarty said:
\n\n\nBredan - I see SCITT as prevention as well, even though it can help with the use case of things went wrong. If it were to provide an allowlist of software, that's prevention. Anything unexpected would not be permitted.
\nThat depends on what you use SCITT for. If you use it for deciding whether to locally install an artifact, then sure, but only if there's no lies in the claim. If there's lies then it doesn't do prevention, only accountability afterwards as Brendan said.
\n
i'm still confused about what value a transparency service actually provides
", "time": "2022-11-10T11:28:10Z"}, {"author": "Brendan Moran", "text": "@Dave Thaler That's not strictly accurate. Recall the \"malicious TAM\" discussions. You may recall that I brought up the scenario where a TAM attempts to install TAs outside its remit. SCITT could be used to trap and prevent that.
", "time": "2022-11-10T11:28:35Z"}, {"author": "Christopher Inacio", "text": "Ned Smith said:
\n\n\nDave Thaler said:
\n\n\nKathleen Moriarty said:
\n\n\nBredan - I see SCITT as prevention as well, even though it can help with the use case of things went wrong. If it were to provide an allowlist of software, that's prevention. Anything unexpected would not be permitted.
\nThat depends on what you use SCITT for. If you use it for deciding whether to locally install an artifact, then sure, but only if there's no lies in the claim. If there's lies then it doesn't do prevention, only accountability afterwards as Brendan said.
\ni'm still confused about what value a transparency service actually provides
\n
I really think of the transparency service as a place that notarizes (as in a traditional legal notary, check your ID, physically stamp the paper) that some statement, like a SBOM, existed saying X on date Y.
", "time": "2022-11-10T11:30:22Z"}, {"author": "Ned Smith", "text": "SBOM = artifact in scitt?
", "time": "2022-11-10T11:30:36Z"}, {"author": "Christopher Inacio", "text": "Ned Smith said:
\n\n\nSBOM = artifact in scitt?
\n
yes, could be.
", "time": "2022-11-10T11:31:01Z"}, {"author": "Ned Smith", "text": "notary is a legal form of non repudiation
", "time": "2022-11-10T11:32:08Z"}, {"author": "Steve Lasker", "text": "Thanks you for the great questions and engagement!
", "time": "2022-11-10T11:32:23Z"}, {"author": "Dave Thaler", "text": "As the scitt arch draft notes, the scitt threat model only addresses Claim authentication and transparency, and confidentiality/privacy. It does not prevent attacks beyond that. You could use it to build something that does other things, assembling scitt together with other techniques.
", "time": "2022-11-10T11:32:29Z"}]