Claims, evidence & provenance

    PDTF carries its assurance story in a separate OIDC4IDA / eIDAS-shaped envelope (pdtf-verified-claims.json). OPDA re-expresses it as a PROV-O backbone plus a separate assurance layer (ODR-0009): PROV-O carries the who / what-process / from-what-evidence skeleton (≈80% of the envelope, native), and the residual eIDAS elements PROV deliberately does not model — signatures, trust framework, assurance tier — are modelled around PROV with dct:, SKOS and a few narrow opda: terms. The backbone classes below are read live from opda-claim.ttl.

    1 · The PROV-O backbone

    PROV-O was chosen over a PROV-O-only model (which flattens evidential weight into a causal trace) and over a bespoke model (which abandons a dereferenceable standard). The core mapping:

    OPDA class⊑ PROV-ORole
    opda:Claimprov:EntityA verifiable claim entity; the verified claim (claim + verification bundle) is a derived entity.
    opda:Evidenceprov:EntityA RoleMixin — a bearer is evidence only qua a VerificationActivity using it; kind is the opda:evidenceType facet, not a subclass.
    opda:AttachedDocumentprov:EntityThe one neutral document Kind; it BECOMES evidence by playing the evidence role, not by sub-classing.
    opda:VerificationActivityprov:ActivityRecords production of a verified claim from evidence; OIDC4IDA `time` → prov:endedAtTime.

    Qualified attribution. The verifier is a prov:Agent (verifier.organization a prov:Organization, a human voucher a prov:Person). OPDA uses the qualified form — prov:qualifiedAttribution → prov:Attribution with prov:hadRole — so validation_method / verification_method are not discarded by the binary prov:wasAttributedTo shortcut. A named procedure (UK AML / MLR 2017 CDD; an identity-assurance profile) is a prov:Plan reached via prov:hadPlan. The convenience predicate opda:supportedBy mirrors the canonical Claim prov:wasDerivedFrom Evidence chain so consumers can query from either end.

    2 · The three truth-makers

    What makes a claim trustworthy decomposes into three orthogonal truth-makers — each homed in the vocabulary that can actually express it, because PROV-O carries only the first:

    Truth-makerWhat it assertsCarried by
    Derivation That the claim was derived from evidence by a verification activity — the causal skeleton. PROV-O native: prov:wasDerivedFrom, opda:VerificationActivity, prov:qualifiedAttribution.
    Signature That the claim or evidence is cryptographically fixed (algorithm + value, e.g. sha256:e3b0…) — PROV has no notion of a signature or hash. Local term opda:digest; algorithm validated against opda:DigestAlgorithmScheme.
    Assurance The quality judgement on the verification — a graded confidence level, not a PROV concept. SKOS-coded opda:AssuranceLevel over opda:AssuranceLevelScheme (§3).

    opda:digest and opda:AssuranceLevel are among the only bespoke opda: terms in this layer (the eIDAS "5-residue" per ODR-0009); everything else reuses PROV-O, dct: or SKOS.

    3 · Assurance levels

    opda:AssuranceLevelScheme is a SKOS scheme (UFO Quality Value) whose members inherit verbatim from eIDAS Regulation (EU) 910/2014 Article 8, plus one OPDA-specific intermediate level ratified by ODR-0009 §Q3. Members read live from opda-vocabularies.ttl:

    LevelSourceNote
    LoweIDAS Art. 8(2)(a)Limited confidence. A vouch-only evidence chain caps here, regardless of voucher quality.
    PDTF-StandardODR-0009 §Q3OPDA-specific intermediate level, for PDTF transactions where a direct eIDAS LoA mapping is not available.
    SubstantialeIDAS Art. 8(2)(b)Substantial confidence — e.g. a court-issued instrument or an authoritative electronic record.
    HigheIDAS Art. 8(2)(c)High confidence in the claimed identity.

    4 · Evidence as a RoleMixin + evidenceType facet

    Evidence is the sharpest application of the classification doctrine (ODR-0027). It is not a subclass tree. opda:Evidence is a UFO RoleMixin (anti-rigid, cross-categorial): a bearer is evidence only qua a VerificationActivity using it — "evidence is a role a document plays", and a Role is never rdfs:subClassOf a Kind. The former DocumentEvidence / ElectronicRecordEvidence / VouchEvidence subclasses are retired.

    The evidence kind is instead a coded isMemberOf classifier: opda:evidenceType over opda:EvidenceMethodScheme — the OIDC4IDA evidence.type value-space, carried as a value, not a class:

    evidenceType valueKindFacet borne by the role
    DocumentA document playing the evidence role (e.g. a grant of probate).Document/filing specifics; the neutral opda:AttachedDocument is the bearer.
    Electronic-RecordAn authoritative electronic record (e.g. an HMRC API tax-record).record.source specifics.
    VouchAn attestation by an agent (e.g. an SRA-solicitor vouch).opda:attestedBy → the voucher prov:Agent; the voucher's role via qualified attribution.

    The three kinds are not collapsed (they remain distinct scheme concepts), and per-kind obligations are validated value-keyed — opda:EvidenceFacetShape targets subjects of opda:evidenceType and uses sh:or material implication (e.g. attestedBy is required only when evidenceType = "Vouch"), never by a class-keyed shape that would require a reasoner to first entail a subtype. rdfs:domain/range on these properties are documentary (ODR-0026 §R2); the real constraint is the SHACL.

    Live opda:EvidenceMethodScheme members: Document Electronic-Record Vouch .

    The claims/evidence exemplars (document / electronic-record / vouch) are on Exemplars; the sh:Violation on an unprovenanced Claim and the EvidenceFacetShape are on SHACL shapes; PII on the opda:Claim Kind is on Governance & PII. Governing records: ODR-0009 (claims/evidence/provenance), ODR-0027 (RoleMixin + facet, retiring the evidence subclass tree).

    Comments

    Loading comments…