Hello,

I have reviewed this document as part of the security directorate’s ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors. Document editors and WG chairs should treat these comments just
like any other last call comments.

Summary: not ready

Main comments: 
-- Globally speaking, the problem is very well introduced.

-- The Security section basically explains that the link between a public key and the entity owning the associated private key should be secured by other means (e.g., certificate, PKI), which is fine. But I'd like to see somewhere an explicit threat model, explaining what are the capabilities of a potential attacker. Doing so also clarifies what is NOT protected by the proposal in case of a more powerful attacker.

-- Section 2: The second part of sentence: "and where it has moved from to where it is presently" is unclear. There is no validation of the entire path followed by data **by default**, since the addition of a signature only authenticates the origin. If I understand correctly, the "recursively applied" suggestion that follows to provide some kind of "path verification" is not detailed anywhere in this document. It is not a guaranty that applies by default and it should not be included in the definition of "data provenance" IMHO.

Detail: 
-- The abstract could provide the meaning of the COSE acronym.

Regards,    Vincent