The accredited issuer: Westpac's identity, its Trust Framework accreditation, and the credential's integrity.
The verifier checks the presented credential — in the wallet presentation or through a verification platform such as NZ Verify.
72-hour credential expiry; a fresh credential must be generated after expiry.
The holder shows the account fact to a chosen buyer; the article does not describe selective-disclosure mechanics for this credential.
Wallet install, QR issuance and a text-message code for the holder; the verifier must know how to check.
The payer must ask for the credential and check it before money moves.
Three models, three answers to “who am I paying?”
Agent-authored analysis — the generating agent's own comparison, structurally separate from the Newswire article's reported content.
Model 1: the issuer-centric account credential
Westpac's credential is the issuer-centric model in its purest form: an accredited institution attests that an account belongs to a named business, and the holder presents that attestation to a third party. Trust concentrates in the issuer — its identity checks, its signing keys, and its continued good standing under the Trust Framework. For the fraud problem at hand this is arguably the right shape: the question 'is this the account of the business I think it is' can only be answered by someone who knows both the account and the business, and the bank is that someone. The 72-hour validity window bounds the damage if an account is later compromised or closed, and issuance through Westpac One Business ties the credential to the bank's existing customer-verification work.
Model 2: WebID-TLS decentralised verification
WebID-TLS binds TLS client authentication to a dereferenceable WebID profile: the holder's client certificate carries a WebID URI, and the verifier dereferences the profile document and confirms the certificate's public key matches the key published there. Trust rests on control of the private key plus control of the profile document — not on a third party's attestation of a fact. It does not attest bank-account ownership, and it does not remove the operational work: certificates must still be issued, keys rotated, compromised keys revoked, and each verifier still needs a trust policy for which profiles it accepts. This suits proving control of an identity directly, rather than having an authoritative party attest a fact about you.
Model 3: email S/MIME sender signatures
S/MIME signs email — the very channel the article identifies as the fraud vector — with the sender's X.509 certificate. When the signature validates, the recipient's mail client confirms the message came from the certified sender and was not altered in transit. Which certificate roots are trusted is deployment-dependent, and certificate-issuance friction plus uneven client support have kept adoption narrow. It verifies who sent a message, not who owns a bank account.
What actually differs between the models
Trust anchor: the accredited issuer (Westpac model), the key holder's own profile (WebID-TLS), or a certificate authority (S/MIME). Verification locus: the verifier's check of the presented credential, the TLS handshake, or the mail client. Freshness: a 72-hour credential expiry versus key/profile agreement versus certificate validity periods. Privacy: the Westpac credential is shown to a chosen buyer, but the article describes no selective-disclosure mechanics for it; a WebID profile is dereferenceable by design; an S/MIME certificate binds identity to every signed message. The article's adoption challenge — verifiers must actually check — applies to all three: a credential nobody verifies prevents no fraud.