Additional identifiers to support Signature Validation Tokens (SVT) should be defined
Razumain opened this issue · 4 comments
A number of identifiers are needed to support SVT.
Current identifiers used in PoC development are listed below.
Identifiers indicating the source of validated time:
/** PDF signature timestamp /
public static final String TIME_VERIFICATION_TYPE_PDF_SIG_TIMESTAMP = "http://id.swedenconnect.se/svt/timeval-type/pdf-sig-timestamp/01";
/* PDF document timestamp /
public static final String TIME_VERIFICATION_TYPE_PDF_DOC_TIMESTAMP = "http://id.swedenconnect.se/svt/timeval-type/pdf-doc-timestamp/01";
/* SVT timestamp */
public static final String TIME_VERIFICATION_TYPE_SVT = "http://id.swedenconnect.se/svt/timeval-type/svt/01";
Identifiers indicating the procedure used to validate a signature
/** Basic signature validation against list of trusted certificates. No revocation checking /
public static final String SIG_VALIDATION_POLICY_BASIC_VALIDATION = "http://id.swedenconnect.se/svt/sigval-policy/basic/01";
/* Full PKIX path validation to a trust anchor including revocation checking of all intermediary and end certificates /
public static final String SIG_VALIDATION_POLICY_PKIX_VALIDATION = "http://id.swedenconnect.se/svt/sigval-policy/pkix/01";
/* Full PKIX path validation allowing revoked certificates revoked after time stamped signing time */
public static final String SIG_VALIDATION_POLICY_TIMESTAMPED_PKIX_VALIDATION = "http://id.swedenconnect.se/svt/sigval-policy/ts-pkix/01";
Policy OID:s
/** Object identifier for the SVT RFC 3161 timestamp policy */
public static final String ID_SVT_TS_POLICY = "1.2.752.201.2.1";
Update. The identifier for signature timestamp can be reused also for XML and other signed document formats allowing signature time stamping (time stamping the signature value). Change this to:
/** PDF signature timestamp /
public static final String TIME_VERIFICATION_TYPE_SIG_TIMESTAMP = "http://id.swedenconnect.se/svt/timeval-type/sig-timestamp/01";
Applications of SVT:s should be documented outside of the eID Framework. I'll keep this issue here, but it should be moved elsewhere.
It is OK to move URI identifiers elsewhere as they are collision free by design. However it is essential that we only have ONE registry for the OID arc. As such, the OID mentioned here MUST be defined in the registry for identifiers.
Only the OID will be added to the registry. The URI:s should be documented elsewhere.