Non-repudiation of origin defines requirements to provide evidence to users/subjects about the identity of the originator of some information. The originator cannot successfully deny having sent the information because evidence of origin (e.g. digital signature) provides evidence of the binding between the originator and the information sent. The recipient or a third party can verify the evidence of origin. This evidence should not be forgeable.
User notes
If the information or the associated attributes are altered in any way, validation of the evidence of origin might fail. Therefore a PP/ST author should consider including integrity requirements such as FDP_UIT.1 Data exchange integrity in the PP/ST.
In non-repudiation there are several different roles involved, each of which could be combined in one or more subjects. The first role is a subject that requests evidence of origin (only in FCO_NRO.1 Selective proof of origin ). The second role is the recipient and/or other subjects to which the evidence is provided (e.g. a notary). The third role is a subject that requests verification of the evidence of origin, for example, a recipient or a third party such as an arbiter.
The PP/ST author must specify the conditions that must be met to be able to verify the validity of the evidence. An example of a condition which could be specified is where the verification of evidence must occur within 24 hours. These conditions, therefore, allow the tailoring of the non-repudiation to legal requirements, such as being able to provide evidence for several years.
In most cases, the identity of the recipient will be the identity of the user who received the transmission. In some instances, the PP/ST author does not want the user identity to be exported. In that case the PP/ST author must consider whether it is appropriate to include this class, or whether the identity of the transport service provider or the identity of the host should be used.
In addition to (or instead of) the user identity, a PP/ST author might be more concerned about the time the information was transmitted. For example, requests for proposals must be transmitted before a certain date in order to be considered. In such instances, these requirements can be customised to provide a timestamp indication (time of origin).