HankoXml::Algorithms

Every algorithm slot accepts either a Symbol (looked up here) or a String URI (used verbatim, subject to Policy).

HankoXml::Algorithms.signature[:rsa_sha256]
# => #<Entry name=:rsa_sha256 uri="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" secure=true>

HankoXml::Algorithms.uri_for(:signature, :rsa_sha256)  # => "http://..."
HankoXml::Algorithms.name_for(:signature, "http://...") # => :rsa_sha256, or nil
HankoXml::Algorithms.secure?(:digest, :sha1)            # => false

HankoXml::Algorithms.register(
  :signature, :hmac_sha512,
  "http://www.w3.org/2001/04/xmldsig-more#hmac-sha512",
  secure: true
)

Registration is process-global and additive. Built-in names and URIs can never be re-registered, even with replace: true; replace: true only replaces an algorithm you registered yourself. Registering does not grant use — a Policy must also allow it. A Policy resolves its allowlists to URIs when it is created, so registering or replacing an algorithm later never changes what an existing policy (including Policy.strict) accepts. That separation means registering an algorithm never silently makes it acceptable to every verifier in the process.

Built-in tables

Canonicalization (Algorithms.canonicalization) — also usable as transforms

Digest (Algorithms.digest)

(The xmlenc / xmldsig-more split for sha256/384/512 is not a typo — it is what the specs say. SHA-3 and RSA-PSS need libxmlsec1 1.3+ to sign or verify; they are still first-class names on xmlsec 1.2, which then fails closed.)

Signature (Algorithms.signature)

Transform (Algorithms.transform) — the canonicalization table above, plus

secure? is a default recommendation, not a hard gate — Policy.strict is a SHA-2 RSA/ECDSA subset, not every secure? name. RSA-PSS and SHA-3 are secure? but only Policy.xades (or Policy#with) allows them. See the Policy reference for how algorithm allowlists interact with these tables.