Attempt clarification of Feed purpose and differentiate from reg_info #107
Conversation
Signed-off-by: Jon Geater <[email protected]>
Signed-off-by: Jon Geater <[email protected]>
JAG-UK
requested review from
henkbirkholz,
ad-l,
fournet and
yogeshbdeshpande
as code owners
|
I've fine taking the changes in this PR as is, but I think Feed should still be removed / replaced with COSE conventions, see #108 |
|
Could someone please describe what a "registered claim name" is? For example, using a "Registry of Deeds" analogy, would Book and Page number,be considered the "registered claim name"? |
|
@rjb4standards in COSE and JOSE, there are names like "iss" and "sub" that are already registered in iana, and there are "private names" like "vendor_branding_info", that are not registered. Registered names are established by updating the registries which requires publishing documents usually. Private names are ones that people decided to use, without registering them. |
|
Fixes #11 |
|
This PR adds clarity and works well with the recent PRs (#113) |
|
Please merge asap |
|
|
||
| Many Issuers issue Signed Statements about different Artifacts under the same DID, so it is important for everyone to be able to immediately recognize by looking at the Envelope of a Signed Statements what Artifact it is referring to. | ||
| Many Issuers produce Signed Statements about various Artifacts under the same Identity. Issuers and Verifiers must be able to recognize the Artifact to which the statements pertain by looking at the Signed Statement. |
There was a problem hiding this comment.
I don't agree that the discriminator for a product is within the signed statements. In the case where product identity is mandated within the artifact, requiring it to be replicated into the detached signature is unclear.
In the use case where there is a global or major Transparency service, I could make a case that the product information hints to auditors more than the frequency of which statements are process, and that may be unacceptable. Right now the information disclosure in a signed detached signature is limited. Can someone make a case why we must\should scope this here? I could see it being necessary for some vertical process.
draft-ietf-scitt-architecture.md
Outdated
|
|
||
| 1. the distributed identifier of the Issuer (or its resolved key manifest), | ||
| 1. the expected name of the Artifact (i.e., the Feed), | ||
| 1. the collection of Transparent Statements to which this Statement about the Artifact belongs (i.e., the Feed), |
There was a problem hiding this comment.
Don't see this working? The verification of a transparent statement should never require binding to a feed. I thought we were talking about feeds for auditors not end users. If so, making it that end user needs to see the Transparency Service directly and "subscribe" has issues.
|
Merging to move the spec forward, with a cleanup PR coming. |
This is an attempt to break the deadlock on Feeds vs searchability etc.
Without making any normative changes (I hope!) I seek to clarify a handful of issues:
Why do we need Feed at all? Because it is the very simple but essential way of ensuring the desired goal of non-equivocation. It makes it practical to discover or eliminate equivocation through a very simple but powerful way of linking related Transparent Statements together, and providing a very simple way of enable pre-commitment for statements of fact and accountability. In less fancy but as useful ways it also ensures that the relying party or someone with a copy of one Transparent Statement in their hands can ensure completeness of the set they're evaluating, and confirm that they are up-to-date with supply chain information that can move very fast.
Does Feed need a structure? No, assuming the above is the purpose of grouping statements together then it doesn't mater what it's called as long as it's the same for all items in the group. This again cements the need for it to be in the Envelope though, since otherwise coordinating all the points in various systems that would need to know what value to put in there would be impractical. By having it in the Envelope anyone with a single Transparent statement from the Feed would know what to use for either making new statements or looking in the TS for related statements.
Can Feed just be a part of reg_info? No, because reg_info is defined for a very different purpose. Registration Policies are also very complicated and need work, but I don't think they need work to close this particular issue.
While there are still clarity issues in the spec which I would love for us to address soon, I think this minimal change makes it possible to move on and removes the pollution from the discussion about types of identity, self-describing serialised data structures, and the like. Crucially, in keeping with the findings from -117, I believe it shows that it is possible to carry the 'findability' information that was required by the applications building on top of SCOITT building blocks without going outside our charter and defining things at the semantic or application layer.