{"id":19894,"date":"2026-09-18T15:04:33","date_gmt":"2026-09-18T15:04:33","guid":{"rendered":"https:\/\/sertifier.com\/blog\/?p=19894"},"modified":"2026-09-18T15:04:33","modified_gmt":"2026-09-18T15:04:33","slug":"issuer-verification-method-rotation","status":"publish","type":"post","link":"https:\/\/sertifier.com\/blog\/issuer-verification-method-rotation\/","title":{"rendered":"Issuer verification-method rotation: a continuity and acceptance plan"},"content":{"rendered":"<p>Rotating an issuer verification method is not complete when a new key exists. It is complete when newly issued credentials use the intended method, verifiers can resolve and accept that method, previously issued credentials still follow the approved validation path, and an accountable record explains the change.<\/p>\n<p>This guide provides a vendor-neutral plan for credential platform architects, security owners and verifier operators. It does not describe Sertifier&#8217;s internal key management, certify a product or prescribe one cryptographic method for every ecosystem.<\/p>\n<div class=\"sertifier-summary-box\">\n<p><strong>Short answer:<\/strong> Test new issuance and historical proof verification separately, preserve explicit method-state decisions and record the accepted activation path without retaining secrets.<\/p>\n<\/div>\n<h2>Short answer<\/h2>\n<p>To rotate a credential issuer&#8217;s verification method safely, inventory every identifier, proof format and verifier dependency first. Add the new method without silently changing the old method&#8217;s meaning, issue synthetic test credentials, confirm that intended verifiers accept the new proof and then switch new issuance. Keep historical verification available for previously issued credentials according to a documented policy. Treat planned rotation, method revocation, credential status and platform migration as different events. Record the old and new method identifiers, activation time, acceptance results, rollback point and final disposition without storing private keys or tokens.<\/p>\n<h2>Scope of this plan<\/h2>\n<p>This plan covers changing the verification material used for new credential proofs while preserving an explicit verification decision for old and new credentials.<\/p>\n<p>For related design decisions, use these guides:<\/p>\n<ul>\n<li>The <a href=\"https:\/\/sertifier.com\/blog\/credential-verification-api\/\">credential verification API guide<\/a> explains hosted, API, cryptographic and wallet verification patterns.<\/li>\n<li>The <a href=\"https:\/\/sertifier.com\/blog\/digital-credential-platform-migration\/\">digital credential migration guide<\/a> covers platform cutover, source-to-target mapping and program migration.<\/li>\n<li>The <a href=\"https:\/\/sertifier.com\/blog\/open-badges-3-explained\/\">Open Badges 3.0 guide<\/a> explains the standard&#8217;s structure, signing model and buyer evaluation.<\/li>\n<li>The <a href=\"https:\/\/sertifier.com\/blog\/digital-credential-interoperability-testing\/\">interoperability acceptance plan<\/a> provides the wider issuer-to-verifier test contract.<\/li>\n<\/ul>\n<p>Use those design decisions as inputs to the rotation runbook. Do not assume that every credential product exposes customer-controlled signing material.<\/p>\n<h2>Separate four events before planning<\/h2>\n<p>Teams often use \u201crotation\u201d for several different changes. That creates unsafe acceptance criteria.<\/p>\n<figure class=\"wp-block-table\">\n<table>\n<thead>\n<tr>\n<th>Event<\/th>\n<th>What changes<\/th>\n<th>Primary question<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Planned verification-method rotation<\/td>\n<td>New proofs move to newly authorized verification material<\/td>\n<td>Can new and historical proofs follow their approved paths?<\/td>\n<\/tr>\n<tr>\n<td>Verification-method revocation<\/td>\n<td>A method is declared no longer acceptable, often because of compromise or policy<\/td>\n<td>From what time and under what evidence must proofs fail?<\/td>\n<\/tr>\n<tr>\n<td>Credential revocation or suspension<\/td>\n<td>The status of an individual credential changes<\/td>\n<td>Is this credential still active under its status method?<\/td>\n<\/tr>\n<tr>\n<td>Platform migration<\/td>\n<td>Records, issuance and verification surfaces move between systems<\/td>\n<td>Does the whole program survive the cutover?<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n<p>The <a href=\"https:\/\/www.w3.org\/TR\/vc-data-integrity\/\" target=\"_blank\" rel=\"noopener\">W3C Verifiable Credential Data Integrity 1.0 Recommendation<\/a> distinguishes a verification method&#8217;s expiry or revocation from a credential&#8217;s own status. A method event concerns the material used to verify a proof. A credential-status event concerns whether the issuer still treats a particular credential as active. Do not convert one into the other automatically.<\/p>\n<h2>Build the dependency inventory<\/h2>\n<p>Begin with the real verification route, not an abstract key name. For every credential profile in scope, record:<\/p>\n<ol>\n<li>The issuer identifier and controller.<\/li>\n<li>The current verification-method identifier.<\/li>\n<li>The proof type, cryptosuite or JOSE algorithm.<\/li>\n<li>The public resolution location, such as a controlled identifier document or JWKS endpoint.<\/li>\n<li>The proof purpose or verification relationship.<\/li>\n<li>Credential and proof validity periods.<\/li>\n<li>Credential-status dependencies.<\/li>\n<li>Every intended verifier, wallet, host or display service.<\/li>\n<li>Caching or refresh behavior for public verification material.<\/li>\n<li>The team accountable for issuance, resolver availability, verification and incident response.<\/li>\n<\/ol>\n<p>The <a href=\"https:\/\/standards.1edtech.org\/open-badges\/guides\/standards\/v3p0\/impl\" target=\"_blank\" rel=\"noopener\">1EdTech Open Badges implementation guide<\/a> describes Open Badges credentials that reference issuer verification material through a verification-method identifier or JWK-based route. It also warns that proof mechanisms are not automatically supported by every host, wallet or verifier. Therefore, a standards-shaped object is not acceptance evidence for the intended receiving systems.<\/p>\n<p>If the route uses a JWK Set, <a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc7517\" target=\"_blank\" rel=\"noopener\">RFC 7517<\/a> defines the <code>kid<\/code> parameter used to match a particular key and recommends distinct <code>kid<\/code> values within a JWK Set. Record the exact identifier that a credential references. \u201cThe JWKS endpoint stayed the same\u201d is not enough to prove that a verifier selected the intended material.<\/p>\n<h2>Define the rotation policy<\/h2>\n<p>A policy should answer why the rotation occurs and what continuity means. Possible triggers include a planned cryptoperiod, a material or algorithm change, an infrastructure transfer, a personnel or control change, or a suspected compromise.<\/p>\n<p><a href=\"https:\/\/csrc.nist.gov\/glossary\/term\/cryptoperiod\" target=\"_blank\" rel=\"noopener\">NIST defines a cryptoperiod<\/a> as the time span during which a key is authorized for use or may remain in effect. That definition does not supply one universal duration. The issuer must set a period appropriate to its system, threat model, algorithm, assurance level and verification dependencies.<\/p>\n<p>Record these decisions before changing anything:<\/p>\n<figure class=\"wp-block-table\">\n<table>\n<thead>\n<tr>\n<th>Decision<\/th>\n<th>Required evidence<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Trigger<\/td>\n<td>Policy date, risk event or approved change request<\/td>\n<\/tr>\n<tr>\n<td>New-issuance activation<\/td>\n<td>Exact time after which new proofs use the new method<\/td>\n<\/tr>\n<tr>\n<td>Old private material<\/td>\n<td>Approved deactivation, archival or destruction treatment<\/td>\n<\/tr>\n<tr>\n<td>Old public verification material<\/td>\n<td>Retention or revocation policy with time semantics<\/td>\n<\/tr>\n<tr>\n<td>Historical proof rule<\/td>\n<td>Whether and how a verifier evaluates a proof made before rotation<\/td>\n<\/tr>\n<tr>\n<td>Credential treatment<\/td>\n<td>Preserve, reissue or revoke under explicit criteria<\/td>\n<\/tr>\n<tr>\n<td>Rollback<\/td>\n<td>Latest point at which new issuance can return to the prior known-good path<\/td>\n<\/tr>\n<tr>\n<td>Evidence retention<\/td>\n<td>Redacted artifacts, owners and retention period<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n<p>Do not put a private key, access token, cookie, recovery secret or unredacted credential into the policy record.<\/p>\n<h2>Establish the pre-rotation baseline<\/h2>\n<p>Create synthetic credentials that cover the combinations your program actually uses. At minimum, include one current positive credential, one expired or inactive credential if supported, one malformed proof, one unknown method and one temporarily unavailable resolver case.<\/p>\n<p>For each case, retain the credential profile and proof format, a safe checksum, the referenced method identifier, the expected verifier state, observed result, timestamp and implementation version. Test direct resolution and the complete reader journey. A command-line proof check does not establish that a wallet, host or hiring system will behave correctly.<\/p>\n<p>The baseline should distinguish at least these outcomes:<\/p>\n<ul>\n<li>accepted;<\/li>\n<li>invalid proof;<\/li>\n<li>inactive credential;<\/li>\n<li>unsupported method or suite;<\/li>\n<li>verification material unavailable;<\/li>\n<li>rejected by verifier policy.<\/li>\n<\/ul>\n<p>If a verifier collapses every non-success result into \u201cinvalid,\u201d record that limitation. An unavailable resolver is an operational incident, not evidence that the credential was forged.<\/p>\n<h2>Use an add, test, activate sequence<\/h2>\n<p>For a planned rotation, prefer a sequence that proves the new path before old signing material is withdrawn.<\/p>\n<ol>\n<li>Prepare the new verification method under the approved control process.<\/li>\n<li>Publish or authorize the new public method without changing old-proof semantics.<\/li>\n<li>Confirm that resolvers return the exact new identifier, controller, method type and verification relationship.<\/li>\n<li>Issue synthetic credentials using the new method.<\/li>\n<li>Test them in every intended verifier and through realistic caches.<\/li>\n<li>Activate the new method for production issuance at the recorded time.<\/li>\n<li>Confirm that a sample of newly issued credentials references only the intended method.<\/li>\n<li>Re-run historical credentials through the approved old-proof path.<\/li>\n<li>Deactivate the old private material under the approved policy.<\/li>\n<li>Monitor failure states and close the change only after the acceptance window passes.<\/li>\n<\/ol>\n<p>The <a href=\"https:\/\/www.w3.org\/TR\/controller-document\/\" target=\"_blank\" rel=\"noopener\">W3C Controlled Identifiers 1.0 Recommendation<\/a> describes rotation as adding new verification material so new proofs can use it, then deactivating or destroying the old secret material. It also notes that proofs relying on a method absent from the latest controller document may need historical state and time information. Availability of that historical route depends on the system. Test it rather than assuming it.<\/p>\n<figure class=\"wp-block-image aligncenter size-large\"><a href=\"https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/09\/historical-proof-decision-path-v1.webp\"><img loading=\"lazy\" decoding=\"async\" width=\"1600\" height=\"964\" src=\"https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/09\/historical-proof-decision-path-v1.webp\" alt=\"Proof context, authenticated method evidence, policy decision and explicit verifier outcome\" class=\"wp-image-19892\" title=\"\" srcset=\"https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/09\/historical-proof-decision-path-v1.webp 1600w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/09\/historical-proof-decision-path-v1-793x478.webp 793w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/09\/historical-proof-decision-path-v1-1120x675.webp 1120w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/09\/historical-proof-decision-path-v1-768x463.webp 768w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/09\/historical-proof-decision-path-v1-1536x925.webp 1536w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/09\/historical-proof-decision-path-v1-780x470.webp 780w\" sizes=\"auto, (max-width: 1600px) 100vw, 1600px\" \/><\/a><figcaption class=\"wp-element-caption\">Evaluate the proof&#8217;s context and method state under the documented policy.<\/figcaption><\/figure>\n<h2>Preserve a decision for historical proofs<\/h2>\n<p>Rotation creates two time questions: which method should sign now, and whether a method was authorized when an older proof was created. The current public document alone might not answer the second question.<\/p>\n<p>Choose one documented approach per credential profile:<\/p>\n<figure class=\"wp-block-table\">\n<table>\n<thead>\n<tr>\n<th>Historical approach<\/th>\n<th>Acceptance requirement<\/th>\n<th>Main risk<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Current document retains old public method<\/td>\n<td>Old proof verifies and the policy still authorizes that method for its creation time<\/td>\n<td>Retention can be mistaken for permission to create new proofs<\/td>\n<\/tr>\n<tr>\n<td>Versioned or historical registry<\/td>\n<td>Verifier retrieves authenticated state for the proof&#8217;s time of interest<\/td>\n<td>Historical state may be unavailable or inconsistently supported<\/td>\n<\/tr>\n<tr>\n<td>Reissue before retirement<\/td>\n<td>Recipient receives a new credential under the new method<\/td>\n<td>Duplicate, notification and consent problems<\/td>\n<\/tr>\n<tr>\n<td>Time-bounded rejection<\/td>\n<td>Old proofs fail after a documented date<\/td>\n<td>Legitimate long-lived credentials can become unusable<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n<p>Do not promise indefinite verification unless the issuer controls and tests every dependency needed for that promise. DNS, resolver availability, method support, archived state and verifier policy can all change.<\/p>\n<h2>Keep compromise response separate<\/h2>\n<p>A suspected compromise is not a routine scheduled rotation. Stop or restrict new issuance under the affected method, preserve incident evidence, determine the affected time window and decide whether method revocation, credential status changes, reissuance or verifier warnings are required.<\/p>\n<p>Do not preserve an old verification path merely to keep a green result if the method should no longer be trusted. Conversely, do not mark every credential invalid only because signing moved to a new method. The incident decision must state how proof creation time, method status and credential status interact.<\/p>\n<p>The rollback plan also changes during compromise. Returning to the old method may be prohibited. A clean emergency method and a separately approved issuance restart can be safer than restoring the previous state.<\/p>\n<h2>Test issuer and verifier responsibilities together<\/h2>\n<figure class=\"wp-block-table\">\n<table>\n<thead>\n<tr>\n<th>Control<\/th>\n<th>Issuer evidence<\/th>\n<th>Verifier evidence<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Identifier binding<\/td>\n<td>New method belongs to the intended controller and proof purpose<\/td>\n<td>Resolution returns the expected controller relationship<\/td>\n<\/tr>\n<tr>\n<td>New issuance<\/td>\n<td>Sample credentials reference the intended new method<\/td>\n<td>Positive cases verify through the real reader path<\/td>\n<\/tr>\n<tr>\n<td>Historical continuity<\/td>\n<td>Old-proof policy and historical material are available<\/td>\n<td>Old cases return the expected state, not an unexplained failure<\/td>\n<\/tr>\n<tr>\n<td>Failure handling<\/td>\n<td>Unknown and unavailable cases are produced safely<\/td>\n<td>Invalid, unsupported and unavailable remain distinguishable<\/td>\n<\/tr>\n<tr>\n<td>Status separation<\/td>\n<td>Credential status treatment is explicit<\/td>\n<td>Method outcome is not confused with credential status<\/td>\n<\/tr>\n<tr>\n<td>Rollback or emergency path<\/td>\n<td>Activation time and allowed fallback are recorded<\/td>\n<td>Verifier detects the intended method state after the decision<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n<p>One passing credential is insufficient. Test each proof format, identifier form and verifier class in scope. A wallet that caches issuer material and an API that resolves it on every request can observe the change at different times.<\/p>\n<figure class=\"wp-block-image aligncenter size-large\"><a href=\"https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/09\/rotation-evidence-bundle-v1.webp\"><img loading=\"lazy\" decoding=\"async\" width=\"1600\" height=\"964\" src=\"https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/09\/rotation-evidence-bundle-v1.webp\" alt=\"Public identifiers, synthetic acceptance cases, accountable change and closure evidence without secrets\" class=\"wp-image-19893\" title=\"\" srcset=\"https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/09\/rotation-evidence-bundle-v1.webp 1600w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/09\/rotation-evidence-bundle-v1-793x478.webp 793w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/09\/rotation-evidence-bundle-v1-1120x675.webp 1120w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/09\/rotation-evidence-bundle-v1-768x463.webp 768w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/09\/rotation-evidence-bundle-v1-1536x925.webp 1536w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/09\/rotation-evidence-bundle-v1-780x470.webp 780w\" sizes=\"auto, (max-width: 1600px) 100vw, 1600px\" \/><\/a><figcaption class=\"wp-element-caption\">Retain reproducible evidence while keeping protected material out of reports.<\/figcaption><\/figure>\n<h2>Retain a secret-safe evidence bundle<\/h2>\n<p>The change record should let an independent reviewer reproduce the decision without exposing sensitive material. Retain:<\/p>\n<ul>\n<li>change and policy identifiers;<\/li>\n<li>old and new public method identifiers;<\/li>\n<li>controller, purpose, method type and algorithm or suite;<\/li>\n<li>approved activation and disposition times;<\/li>\n<li>synthetic fixture checksums and expected results;<\/li>\n<li>resolver and verifier implementation versions;<\/li>\n<li>redacted responses for positive, negative and unavailable cases;<\/li>\n<li>accountable issuer, verifier and security approvals;<\/li>\n<li>rollback or emergency decision;<\/li>\n<li>post-activation monitoring and closure evidence.<\/li>\n<\/ul>\n<p>Keep secret keys, tokens and cookies in their protected systems. A report can state that controlled material was generated, activated or destroyed without copying it.<\/p>\n<h2>Check your platform&#8217;s verification capabilities<\/h2>\n<p>Current public <a href=\"https:\/\/help.sertifier.com\/how-can-i-verify-my-certificate\">Sertifier verification documentation<\/a> describes hosted credential verification, credential-ID search, branded verification pages and organization-level issuer verification. These sources do not document customer-controlled signing keys, JWKS, DIDs, cryptosuite selection or rotation schedules.<\/p>\n<p>For a Sertifier program, begin by testing the documented hosted reader journey. If your implementation also requires a particular signing method or historical proof behavior, confirm those requirements through a scoped implementation review before choosing the rotation design. A public \u201cverified issuer\u201d label alone does not establish the platform&#8217;s internal cryptographic controls.<\/p>\n<h2>Rotation acceptance checklist<\/h2>\n<ul>\n<li>The change has one accountable owner and approved trigger.<\/li>\n<li>Issuer, method, proof, status, resolver and verifier dependencies are inventoried.<\/li>\n<li>The proposed method identifier is unique and resolves to the intended controller and purpose.<\/li>\n<li>Synthetic positive, negative, unavailable and historical fixtures exist.<\/li>\n<li>The old and new verification paths have explicit expected states.<\/li>\n<li>New issuance does not begin before intended verifiers accept the new method.<\/li>\n<li>Historical proof behavior is tested, not assumed.<\/li>\n<li>Credential status and method status remain separate.<\/li>\n<li>Planned rotation and compromise response use separate decision paths.<\/li>\n<li>No secrets or real learner data enter the evidence bundle.<\/li>\n<li>A rollback or emergency issuance path is approved before activation.<\/li>\n<li>Monitoring has a defined window, threshold and accountable responder.<\/li>\n<\/ul>\n<h2>Measure the change<\/h2>\n<p>Operational acceptance should report counts by verifier state and credential cohort, not a single success percentage. Separate old-method historical cases, new-method cases, unsupported verifiers, unavailable resolvers, invalid proofs and policy rejections.<\/p>\n<div class=\"sertifier-conversion-cta\">\n<p><strong>Check the verification journey your program uses<\/strong><\/p>\n<p>Review Sertifier&#8217;s documented hosted verification route. Confirm any signing-method or historical-proof requirements through a scoped implementation review.<\/p>\n<p><a class=\"wp-block-button__link wp-element-button\" href=\"https:\/\/help.sertifier.com\/how-can-i-verify-my-certificate\">Read the credential verification guide<\/a><\/p>\n<\/div>\n<h2>Frequently asked questions<\/h2>\n<h3>Is key rotation the same as credential revocation?<\/h3>\n<p>No. Rotation changes the verification material used for proofs. Credential revocation changes the status of an individual credential. A rotation policy must state whether any credentials require a separate status action.<\/p>\n<h3>Must every credential be reissued after rotation?<\/h3>\n<p>No universal rule requires that. Reissuance depends on the historical verification model, compromise evidence, credential lifetime, verifier support and program policy. Test the intended old-proof path before deciding.<\/p>\n<h3>Can the old public method remain available?<\/h3>\n<p>It can remain available under some designs so earlier proofs can be checked, but availability is not the same as permission to create new proofs. Record the method&#8217;s time semantics and verifier policy explicitly.<\/p>\n<h3>What should a verifier return if issuer material is temporarily unavailable?<\/h3>\n<p>Return an unavailable or indeterminate state rather than silently treating the credential as valid or definitively invalid. Retain enough diagnostic detail to retry safely without exposing sensitive data.<\/p>\n<h3>Does using Open Badges or Verifiable Credentials solve rotation automatically?<\/h3>\n<p>No. Standards define structures and processing expectations, but resolver history, method support, caching and verifier policy still vary. Acceptance testing is required for the intended combination of systems.<\/p>\n<h3>Does Sertifier let customers manage signing keys or rotation schedules?<\/h3>\n<p>The current public documentation reviewed for this guide does not establish that capability. Verify the current product contract directly before making a design or procurement decision.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Plan verification-method rotation for credential issuers with new-proof acceptance, historical verification, incident separation and a secret-safe evidence bundle.<\/p>\n","protected":false},"author":3,"featured_media":19891,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"","rank_math_description":"","rank_math_focus_keyword":"","rank_math_canonical_url":"","footnotes":""},"categories":[939],"tags":[],"class_list":["post-19894","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-digital-credentials"],"_links":{"self":[{"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/posts\/19894","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/comments?post=19894"}],"version-history":[{"count":1,"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/posts\/19894\/revisions"}],"predecessor-version":[{"id":19895,"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/posts\/19894\/revisions\/19895"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/media\/19891"}],"wp:attachment":[{"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/media?parent=19894"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/categories?post=19894"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/tags?post=19894"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}