ମାର୍ଗଦର୍ଶିକା

ସହିତ AI ଏଜେଣ୍ଟ ଅନୁରୋଧଗୁଡ଼ିକୁ କିପରି ସତ୍ୟାପନ କରିବେ

ସ୍ୱୟଂଚାଳିତ client ଠାରୁ RFC 9421 signature ସତ୍ୟାପନ କରିବା, ଏକ ବ valid signature କ’ଣ ପ୍ରମାଣ କରେ, ଏବଂ ଆପଣଙ୍କ logs କ’ଣ ଧରି ରଖିବା ଉଚିତ - ଏହାର ଏକ ବ୍ୟବହାରିକ walkthrough.

ଦ୍ୱାରା Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

ଉନ୍ନତ · 11 ମିନିଟ୍ ପଢ଼ନ୍ତୁ

ସହିତ ଅନୁରୋଧ କ’ଣ ପ୍ରମାଣ କରେ?

ଅଧିକାଂଶ ସ୍ୱୟଂଚାଳିତ traffic ନିଜକୁ user agent string ଦ୍ୱାରା ପରିଚୟ କରାଏ। ସେହି string ଏକ ଦାବି, ଏବଂ ଏହାକୁ କପି କରିବାରେ କିଛି ଖର୍ଚ୍ଚ ନାହିଁ। ସହିତ ଅନୁରୋଧଗୁଡ଼ିକ ଏହି ପରିସ୍ଥିତିକୁ ବଦଳାଏ। ଯେତେବେଳେ ଏକ ସ୍ୱୟଂଚାଳିତ client ନିଜର private key ସହିତ HTTP requests ସହି କରେ ଏବଂ operator ସହିତ ସଂଯୁକ୍ତ ଏକ ସ୍ଥାନରେ ମେଳାଉଥିବା public key ପ୍ରକାଶ କରେ, ଆପଣଙ୍କ server ଯାଞ୍ଚ କରିପାରେ ଯେ ଅନୁରୋଧଟି ସେହି key ଧାରଣ କରୁଥିବା କାହାରୋ ଦ୍ୱାରା ସତ୍ୟରେ ଉତ୍ପାଦିତ ହୋଇଥିଲା।

ଏହାର ପଛରେ ଥିବା standard ହେଉଛି HTTP Message Signatures, ଯାହା RFC 9421 ଭାବେ ପ୍ରକାଶିତ। IETF Web Bot Auth working group ସ୍ୱୟଂଚାଳିତ client ମାନଙ୍କ ପାଇଁ convention ଉପରେ ଏହାକୁ ଆଧାର କରେ: ଏକ agent କିପରି ନିଜ key directory କୁ ସୂଚାଏ ଏବଂ କେଉଁ request component ଗୁଡ଼ିକୁ ଏହା ସହି କରିବା ଉଚିତ। November 2026 ପର୍ଯ୍ୟନ୍ତ, working group ର protocol document ହେଉଛି draft-ietf-webbotauth-httpsig-protocol, ଯାହା Signature-Agent header, JSON Web Key Sets ଉପରେ ଆଧାରିତ key directory format, ଏବଂ ଏହାକୁ ସର୍ଭ କରିବା ପାଇଁ ଏକ well-known URI କୁ ପରିଭାଷା କରେ। ଦୁହେଁକୁ ଖୁବ ଭଲଭାବରେ ବୁଝିବା ଯୋଗ୍ୟ, କାରଣ verification ସହଜରେ ସୂକ୍ଷ୍ମ ଭାବରେ ଭୁଲ ହୋଇପାରେ।

mechanics କୁ ପୂର୍ବରୁ, ଫଳାଫଳ ସମ୍ପର୍କରେ ସ୍ପଷ୍ଟ ରୁହନ୍ତୁ। ଏକ valid signature ଦର୍ଶାଏ ଯେ ଅନୁରୋଧଟି operator ଙ୍କ domain ପରି ଏକ ପ୍ରକାଶିତ identifier ସହିତ ସଂଯୁକ୍ତ ଏକ key ଦ୍ୱାରା ସହିତ ହୋଇଥିଲା, ଏବଂ ଅନୁରୋଧର signed ଅଂଶଗୁଡ଼ିକ ପରିବର୍ତ୍ତିତ ହୋଇନଥିଲା। ଏହା ଦର୍ଶାଏନାହିଁ କି agent କୁ କିଏ ନିର୍ଦ୍ଦେଶ ଦେଲା, କିଏ ଏକ ଲୋକ ଏହାକୁ authority ଦେଲା, କିମ୍ବା କାର୍ଯ୍ୟଟି ସୁରକ୍ଷିତ କି ନୁହେଁ। identity evidence ଏବଂ authorization ପୃଥକ ପ୍ରଶ୍ନ, ଏବଂ ଆପଣଙ୍କ application ଦ୍ୱିତୀୟଟିର ଉତ୍ତର ଦିଏ। what signed AI agent requests prove ଉପରେ ଆମ blog post ସେହି boundary କୁ ଉଦାହରଣ ସହିତ ବିସ୍ତାର କରେ।

ଏକ ସହିତ ଅନୁରୋଧ ସାଧାରଣତଃ ତିନିଟି header ବହନ କରେ:

Signature-Input (RFC 9421, Section 4.1) ପ୍ରତ୍ୟେକ signature କୁ ବର୍ଣ୍ଣନା କରେ: ଏକ label, covered components ର ତାଲିକା, ଏବଂ created, expires, keyid, alg, nonce ଏବଂ tag ପରି parameter.
Signature (RFC 9421, Section 4.2) structured field ଭାବରେ ପ୍ରତ୍ୟେକ label ପାଇଁ signature bytes, base64 encoded, ବହନ କରେ।
Signature-Agent (Web Bot Auth convention ଠାରୁ) client ଙ୍କ public key କେଉଁଠାରେ ପ୍ରକାଶିତ ହୋଇଛି ସେଥିକୁ ସୂଚାଏ, ସାଧାରଣତଃ operator ଙ୍କ domain ଉପରେ ଏକ HTTPS URL ।

ଏକ ସରଳ ଉଦାହରଣ:

HTTP

GET /api/catalog?page=2 HTTP/1.1
Host: shop.example
Signature-Agent: "https://agent.example"
Signature-Input: sig1=("@method" "@authority" "@path" "signature-agent");created=1762934400;expires=1762934700;keyid="kq1";alg="ed25519";tag="web-bot-auth";nonce="d9f1c2"
Signature: sig1=:Base64SignatureBytes==:

ଦୃଶ୍ୟତା ପାଇଁ ଉଦାହରଣଟି ସରଳ କରାଯାଇଛି। ବର୍ତ୍ତମାନର working group draft ରେ, Signature-Agent ନିଜେ signature label ଦ୍ୱାରା keyed ଏକ structured field (ଉଦାହରଣ ସ୍ୱରୂପ sig1="https://agent.example") ଅଟେ, ସେହିପାଇଁ ଆପଣଙ୍କ verification library କେଉଁ form ଆଶା କରେ ସେଥିକି ଯାଞ୍ଚ କରନ୍ତୁ।

ପଦକ୍ଷେପ 1: structured field କୁ ଠିକ୍ ଭାବରେ parse କରନ୍ତୁ

Signature-Input ଏବଂ Signature ହେଉଛି HTTP Structured Fields (RFC 9651, ଯାହା RFC 8941 କୁ obsolete କରେ)। ସେଗୁଡ଼ିକୁ string splitting ଦ୍ୱାରା parse କରନ୍ତୁ ନାହିଁ। Quoted string, parameter ଏବଂ inner list ଗୁଡ଼ିକର ସମସ୍ତଙ୍କର ସଠିକ୍ grammar ଅଛି, ଏବଂ ଅବହେଳାପୂର୍ଣ୍ଣ parser ଦୁଇଟି ସମସ୍ୟା ଉତ୍ପନ୍ନ କରେ: ଭୁଲ rejection ଏବଂ ପ୍ରକୃତ security gap।

ଏକ maintained structured-field parser ବ୍ୟବହାର କରନ୍ତୁ, କିମ୍ବା ତାହାଠାରୁ ଭଲ, parsing ଏବଂ verification କୁ ଏକାସାଙ୍ଗରେ ସମ୍ଭାଳୁଥିବା ଏକ maintained RFC 9421 library ବ୍ୟବହାର କରନ୍ତୁ। specification କୁ scratch ଠାରୁ implement କରିବା ଏକ ଭଲ learning exercise, କିନ୍ତୁ production ପାଇଁ ଖରାପ ପସନ୍ଦ। ତଳେ ଥିବା ପଦକ୍ଷେପଗୁଡ଼ିକ ସେହିପରି library କ’ଣ କରେ ସେଥିକୁ ବର୍ଣ୍ଣନା କରେ, ଯାହାଦ୍ୱାରା ଆପଣ ଏହାକୁ ଠିକ୍ ଭାବରେ configure କରିପାରିବେ ଏବଂ ଏହାର output ସମୀକ୍ଷା କରିପାରିବେ।

ପଦକ୍ଷେପ 2: କେଉଁ signature ମୂଲ୍ୟାୟନ କରିବେ ତାହା ବାଛନ୍ତୁ

ଏକ request ରେ ଏକାଧିକ signature label ଥାଇପାରେ। ଆପଣଙ୍କ policy ସହିତ ମେଳ ହେଉଥିବାଟି ବାଛନ୍ତୁ, ଉଦାହରଣ ସ୍ୱରୂପ ସେହି label ଯାହାର tag web-bot-auth ଅଟେ। ଯଦି:

କୌଣସି signature ଆପଣ ଆବଶ୍ୟକ କରୁଥିବା parameter ନଥାଏ,
algorithm ଆପଣଙ୍କ allowlist ରେ ନଥାଏ (ଉଦାହରଣ ସ୍ୱରୂପ ed25519), କିମ୍ବା
covered component ଗୁଡ଼ିକ ଆପଣ ଆବଶ୍ୟକ କରୁଥିବା minimum set କୁ ସାମିଲ ନକରନ୍ତି,

ତେବେ verification ଉଦ୍ଦେଶ୍ୟ ପାଇଁ ଅନୁରୋଧଟିକୁ reject କରନ୍ତୁ (serving ଉଦ୍ଦେଶ୍ୟ ପାଇଁ ନୁହେଁ)।

ସ୍ୱୟଂଚାଳିତ client ପାଇଁ ଏକ ଯୁକ୍ତିସଙ୍ଗତ minimum ହେଉଛି @method, @authority ଏବଂ @path, ଏବଂ ସେ header ଥାଇଲେ signature-agent। @authority ବିନା, ଗୋଟିଏ site ପାଇଁ captured ହୋଇଥିବା signature କୁ ଅନ୍ୟ site ବିରୋଧରେ replay କରାଯାଇପାରେ। @path ବିନା, ଏହା endpoints across re-use କରାଯାଇପାରେ। Web Bot Auth protocol draft agents କୁ @authority କିମ୍ବା @target-uri ସାମିଲ କରିବାକୁ ଆବଶ୍ୟକ କରେ, ଏବଂ ଚେତାବନୀ ଦିଏ ଯେ କେବଳ authority କୁ cover କରୁଥିବା signature ସେହି host ଉପରେ କୌଣସି method କିମ୍ବା path ବିରୋଧରେ, expiry ପର୍ଯ୍ୟନ୍ତ, valid ରହେ।

ପଦକ୍ଷେପ 3: time parameter ଯାଞ୍ଚ କରନ୍ତୁ

RFC 9421, Section 2.3 ରେ ପରିଭାଷିତ time parameter created ଏବଂ expires ପଢ଼ନ୍ତୁ। ତାପରେ:

ଛୋଟ clock skew allowance ଠାରୁ ଅଧିକ future ରେ ଥିବା created time ସହ signature ଗୁଡ଼ିକୁ reject କରନ୍ତୁ।
expires ପାର୍ ହୋଇଥିବା signature ଗୁଡ଼ିକୁ reject କରନ୍ତୁ।
ଯଦି expires ନାହିଁ, created ଉପରେ ଆଧାରିତ ଆପଣଙ୍କ own maximum age enforce କରନ୍ତୁ।

ଛୋଟ validity window ଏକ captured ଅନୁରୋଧ କେତେ ସମୟ replay ହୋଇପାରିବ ସେଥିକୁ ସୀମିତ କରେ।

ପଦକ୍ଷେପ 4: key ଖୋଜନ୍ତୁ

Signature-Agent header operator ଙ୍କ key directory କୁ ସୂଚାଏ। ଏହାକୁ HTTPS ଦ୍ୱାରା fetch କରନ୍ତୁ, ଏବଂ କେବଳ HTTPS ଦ୍ୱାରା। Web Bot Auth protocol draft directory କୁ JSON Web Key Set (keys in JWK format) ଭାବରେ ବର୍ଣ୍ଣନା କରେ, ଯାହା http-message-signatures-directory well-known URI ରେ ସେହି origin ଠାରୁ ସର୍ଭ ହୁଏ। ତାପରେ ସେ key ଖୋଜନ୍ତୁ ଯାହାର identifier keyid parameter ସହିତ ମେଳ ଖାଏ।

type Jwk = { kid: string; kty: string; crv?: string; x?: string };

const keyCache = new Map<string, { keys: Jwk[]; fetchedAt: number }>();
const KEY_TTL_MS = 60 * 60 * 1000;

export async function getKey(directoryUrl: string, keyId: string): Promise<Jwk | null> {
  const url = new URL(directoryUrl);
  if (url.protocol !== "https:") return null;

  const cached = keyCache.get(url.origin);
  const fresh = cached && Date.now() - cached.fetchedAt < KEY_TTL_MS;
  const keys = fresh ? cached.keys : await fetchKeys(url.origin);
  return keys.find((k) => k.kid === keyId) ?? null;
}

async function fetchKeys(origin: string): Promise<Jwk[]> {
  const res = await fetch(`${origin}/.well-known/http-message-signatures-directory`, {
    headers: { accept: "application/http-message-signatures-directory+json, application/json" },
    signal: AbortSignal.timeout(2000),
  });
  if (!res.ok) return [];
  const body = (await res.json()) as { keys?: Jwk[] };
  const keys = Array.isArray(body.keys) ? body.keys : [];
  keyCache.set(origin, { keys, fetchedAt: Date.now() });
  return keys;
}

key discovery ପାଇଁ ବ୍ୟବହାରିକ ନିୟମଗୁଡ଼ିକ:

verification ପ୍ରତ୍ୟେକ request ରେ network call ଯୋଗ ନକରିବା ପାଇଁ bounded lifetime ସହ key cache କରନ୍ତୁ।
ଛୋଟ timeout ନିର୍ଦ୍ଧାରଣ କରନ୍ତୁ ଏବଂ ଏକ failed fetch କୁ "could not verify" ଭାବରେ ଧରନ୍ତୁ, କେବେ ମଧ୍ୟ "verified" ଭାବରେ ନୁହେଁ।
ଯଦି ସମ୍ଭବ, ଆପଣ କେଉଁ origin ଠାରୁ fetch କରୁଛନ୍ତି ସେଥିକୁ ସୀମିତ କରନ୍ତୁ, କିମ୍ବା କମ୍ ସେ କମ୍ private address range ବ୍ଲକ୍ କରନ୍ତୁ ଯାହାଦ୍ୱାରା server-side request forgery ଏଡ଼ାଯାଇପାରିବ। protocol draft ଏହି security consideration ରେ ଠିକ୍ ଏହି କାରଣକୁ ନେଇ server-side request forgery ତାଲିକାଭୁକ୍ତ କରେ।
user agent ର free-text name ଉପରେ ନୁହେଁ, origin ସହ identity କୁ bind କରନ୍ତୁ। ଆପଣ ଯେ identifier record କରନ୍ତି ସେ directory origin ଅଟେ।

ପଦକ୍ଷେପ 5: signature base ପୁନର୍ଗଠନ କରନ୍ତୁ

signer raw request ସହି କରିନଥିଲେ। ସେ canonical string ଉପରେ ସହି କରିଥିଲା ଯାହାକୁ signature base (RFC 9421, Section 2.5) କୁହାଯାଏ, ଯାହା covered components ଠାରୁ କ୍ରମରେ ଗଠିତ, ପରେ @signature-params line ଆସେ। ଆପଣଙ୍କ verifier received request ଠାରୁ ସେହି string କୁ ପୁନର୍ଗଠନ କରେ।

ଉପରୋକ୍ତ ଉଦାହରଣ ପାଇଁ base ଏଭଳି ଦେଖାଯାଏ:

TEXT

"@method": GET
"@authority": shop.example
"@path": /api/catalog
"signature-agent": "https://agent.example"
"@signature-params": ("@method" "@authority" "@path" "signature-agent");created=1762934400;expires=1762934700;keyid="kq1";alg="ed25519";tag="web-bot-auth";nonce="d9f1c2"

proxy ପଛରେ verification ଭାଙ୍ଗିଦେଉଥିବା ବିବରଣୀଗୁଡ଼ିକୁ ଧ୍ୟାନ ଦିଅନ୍ତୁ:

@authority client ଲକ୍ଷ୍ୟ କରିଥିବା host ହେବା ଉଚିତ। ଯଦି load balancer Host ପୁନଲିଖନ କରେ, ତେବେ ସେ ଆଗକୁ ପଠାଇଥିବା original value ବ୍ୟବହାର କରନ୍ତୁ।
@path query string କୁ ବାଦ ଦିଏ। ଯଦି client @query କୁ cover କରିଥିଲା, ତେବେ ଏହାକୁ ଯେପରି ଆସିଥିଲା ସେହିପରି ପୁନର୍ଗଠନ କରନ୍ତୁ।
header value ଗୁଡ଼ିକ specified ଭଳି canonicalize କରାଯାଏ: trimmed ହୋଇ, multiple value ସମ୍ମିଳିତ କରାଯାଏ। ଏକ ଭଲ library ଏହା ଆପଣଙ୍କ ପାଇଁ କରେ।

ପଦକ୍ଷେପ 6: signature ସତ୍ୟାପନ କରନ୍ତୁ

base ଏବଂ public key ସହ, RFC 9421, Section 3.2 ର ପଦକ୍ଷେପ ଅନୁସରି verification ଗୋଟିଏ single call ଅଟେ। Node.js ରେ Ed25519 ପାଇଁ, built-in crypto module ବ୍ୟବହାର କରି:

import { createPublicKey, verify } from "node:crypto";

export function verifyEd25519(jwk: Jwk, base: string, signatureB64: string): boolean {
  const key = createPublicKey({ key: jwk as any, format: "jwk" });
  return verify(null, Buffer.from(base, "utf8"), key, Buffer.from(signatureB64, "base64"));
}

ଯଦି check ବିଫଳ ହୁଏ, ଅନୁରୋଧ verified ନୁହେଁ। ଏହା ତଥାପି serve ହୋଇପାରେ। ଏହା କେବଳ "verified" basis ପାଉନାହିଁ।

ପଦକ୍ଷେପ 7: replay ବନ୍ଦ କରନ୍ତୁ

ଏକ valid signature ଧରାଯାଇ expiry ପର୍ଯ୍ୟନ୍ତ ପୁନଃପଠାଯାଇପାରେ। RFC 9421, Section 7.2.2 signature replay କୁ ଆବର୍ତ୍ତିତ କରେ, ଏବଂ Web Bot Auth protocol draft ନିଜର nonce ନିୟମ ଯୋଡ଼ିବା ପରିବର୍ତ୍ତେ ଏହାକୁ ଅନୁସରେ। ଦୁଇଟି control ସେ window ର ଅଧିକାଂଶ ଅଂଶ ବନ୍ଦ କରେ:

ଛୋଟ expiry, ପଦକ୍ଷେପ 3 ରେ enforce କରାଯାଇଥିବା।
Nonce tracking. ଯେତେବେଳେ nonce ଉପସ୍ଥିତ ଥାଏ, ଏହାକୁ ଏହାର key identifier ସହ signature expire ହେଉ ପର୍ଯ୍ୟନ୍ତ shared store ରେ ସଂରକ୍ଷଣ କରନ୍ତୁ, ଏବଂ ଦ୍ୱିତୀୟ ବ୍ୟବହାରକୁ reject କରନ୍ତୁ।

const seen = new Map<string, number>();

export function acceptNonce(keyId: string, nonce: string, expiresAt: number): boolean {
  const id = `${keyId}:${nonce}`;
  const now = Date.now() / 1000;
  for (const [k, exp] of seen) if (exp < now) seen.delete(k);
  if (seen.has(id)) return false;
  seen.set(id, expiresAt);
  return true;
}

multi-instance deployment ରେ, remaining validity ସହ ସମାନ time to live ଥିବା Redis ପରି shared store ରେ nonce ରଖନ୍ତୁ।

ପଦକ୍ଷେପ 8: basis ସହିତ ଫଳାଫଳ record କରନ୍ତୁ

Verification evidence ଉତ୍ପାଦନ କରେ, verdict ନୁହେଁ। ଏହାକୁ ଏକ ଏମିତି ରୂପରେ record କରନ୍ତୁ ଯାହାକୁ ଆପଣଙ୍କ analytics ଏବଂ policy ବ୍ୟବହାର କରିପାରିବ:

const result = {
  actor: "agent",
  basis: "verified",
  operator: "https://agent.example",
  keyId: "kq1",
  coveredComponents: ["@method", "@authority", "@path", "signature-agent"],
  verifiedAt: new Date().toISOString(),
};

ଯେତେବେଳେ verification ବିଫଳ ହୁଏ କିମ୍ବା ଚାଲିପାରେନାହିଁ, ସେଥିକୁ ମଧ୍ୟ record କରନ୍ତୁ, କାରଣ ସହ: missing headers, unsupported algorithm, key not found, expired, replayed, କିମ୍ବା signature mismatch। ଏହି reason ଗୁଡ଼ିକ ମୂଲ୍ୟବାନ। ଗୋଟିଏ operator ଠାରୁ "key not found" ର spike ସାଧାରଣତଃ ସେମାନେ key rotate କରିଛନ୍ତି ବୋଲି ସୂଚାଏ, ସେମାନେ ଆପଣଙ୍କୁ attack କରୁଛନ୍ତି ବୋଲି ନୁହେଁ।

signature verification ଠାରୁ ଆପଣ କ’ଣ log କରିବେ?

operator origin, key identifier, covered components, time parameter, outcome ଏବଂ failure reason log କରନ୍ତୁ। full signature bytes କିମ୍ବା ସମ୍ପୂର୍ଣ୍ଣ request body log କରନ୍ତୁ ନାହିଁ। patterns study କରିବା ପର୍ଯ୍ୟନ୍ତ ଏବଂ ଆପଣଙ୍କ privacy commitment ସମ୍ମାନ କରିବା ପର୍ଯ୍ୟନ୍ତ logs ରଖନ୍ତୁ, କିନ୍ତୁ ସେଗୁଡ଼ିକୁ ଅତ୍ୟଧିକ ଦୀର୍ଘ କରନ୍ତୁ ନାହିଁ।

ଏକ verified signature ଆପଣଙ୍କ policy କୁ କିପରି ପରିବର୍ତ୍ତନ କରିବ?

ଏକବାର ଅନୁରୋଧଗୁଡ଼ିକୁ verified କରାଯାଇପାରିଲେ, ଆପଣ ସେଗୁଡ଼ିକୁ ଅର୍ଥପୂର୍ଣ୍ଣ ଭାବେ ଭିନ୍ନ ଭାବରେ ପରିଚାଳନା କରିପାରିବେ। humans and AI agents ପାଇଁ app policies design କରିବା ଉପରେ ଆମ post ବ୍ୟାପକ policy model କୁ କଭର କରେ:

unverified automation ଠାରୁ ଅଧିକ rate limit ସହ read-only route ଉପରେ verified operator ମାନଙ୍କୁ allow କରନ୍ତୁ।
full HTML page ପରିବର୍ତ୍ତେ JSON କିମ୍ବା Markdown ପରି structured response ପ୍ରଦାନ କରନ୍ତୁ।
high-impact action ଗୁଡ଼ିକୁ ଆପଣଙ୍କ normal authorization ପଛରେ ରଖନ୍ତୁ। ଏକ verified signature ଆପଣଙ୍କୁ କେଉଁ client call କରୁଛି ତାହା କୁହେ, ଏହା account ପରିବର୍ତ୍ତନ କରିପାରିବ କି ନୁହେଁ ସେଥିକି କୁହେନାହିଁ।

observation mode ରେ ଆରମ୍ଭ କରନ୍ତୁ। ଆପଣଙ୍କ automated traffic ର କେତେ ଅଂଶ signed, କେଉଁ operator ଦେଖାଯାନ୍ତି, ଏବଂ verification କେତେଥର ବିଫଳ ହୁଏ, ସେଥିକୁ ମାପନ କରନ୍ତୁ, କୌଣସି policy ଏହାର ଉପରେ ନିର୍ଭର କରିବା ପୂର୍ବରୁ।

Proof of Actor କେଉଁଠି fit ହୁଏ

Signature verification ଅନେକ evidence ଉତ୍ସମାନଙ୍କ ମଧ୍ୟରୁ ଗୋଟିଏ। Proof of Actor ଏହାକୁ ଅନ୍ୟ signals ସହିତ ଯୋଡ଼େ ଏବଂ ପ୍ରତ୍ୟେକ result ଉପରେ basis visible ରଖେ, ଯାହାଦ୍ୱାରା ଏକ verified agent କେବେବି କେବଳ ନିଜକୁ declared କରିଥିବା ଏକ ସହିତ ଭ୍ରମିତ ହୁଏନାହିଁ। ଆପଣଙ୍କ application ପରବର୍ତ୍ତୀରେ କ’ଣ ଘଟିବ ସେଥିକି ନିଷ୍ପତ୍ତି କରେ।

ଆମ engineer ମାନଙ୍କ ସହିତ ଏହାକୁ production app ରେ build କରିବାକୁ, apply for early access କରନ୍ତୁ। evidence କ’ଣ ଦେଖାଇପାରେ ଏବଂ କ’ଣ ଦେଖାଇପାରେନାହିଁ ସେଥିର ସମ୍ପୂର୍ଣ୍ଣ ଚିତ୍ର ପାଇଁ, Detection & Limitations ପଢ଼ନ୍ତୁ।

ଉତ୍ସଗୁଡ଼ିକ

RFC 9421: HTTP Message Signatures: signing ଏବଂ verification standard, signature parameter, signature base ଏବଂ replay consideration ସହ
RFC 9651: Structured Field Values for HTTP: Signature-Input ଏବଂ Signature ଦ୍ୱାରା ବ୍ୟବହୃତ grammar
IETF Web Bot Auth working group: automated client authentication କାମର charter ଏବଂ status
draft-ietf-webbotauth-httpsig-protocol: Signature-Agent, JWKS key directory ଏବଂ ଏହାର well-known URI ପରିଭାଷା କରୁଥିବା Internet-Draft (November 2026 ପର୍ଯ୍ୟନ୍ତ work in progress)
RFC 7517: JSON Web Key (JWK): ପ୍ରକାଶିତ key directory ଗୁଡ଼ିକରେ ବ୍ୟବହୃତ key format
RFC 8615: Well-Known URIs: key directory ପରି well-known path କିପରି register ହୁଏ
RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA): ଉଦାହରଣରେ ବ୍ୟବହୃତ Ed25519 algorithm
Node.js crypto documentation: ପଦକ୍ଷେପ 6 ରେ ବ୍ୟବହୃତ createPublicKey ଏବଂ verify

ଆମ ସହିତ ଏହା ତିଆରି କରନ୍ତୁ।

Proof of Actor founding developer program ରେ ଯୋଗଦିଅନ୍ତୁ।

Early Access ପାଆନ୍ତୁ ଡେଭେଲପର୍ କେନ୍ଦ୍ର

ପ୍ରଥମେ କଥାହେବାକୁ ପସନ୍ଦ କରନ୍ତି? founderମାନଙ୍କ ସହ କଥାବାର୍ତ୍ତା କରନ୍ତୁ