'%3e%3cpath%20fill-rule='evenodd'%20clip-rule='evenodd'%20d='M6.99935%2012.8327C10.221%2012.8327%2012.8327%2010.221%2012.8327%206.99935C12.8327%203.77769%2010.221%201.16602%206.99935%201.16602C3.77769%201.16602%201.16602%203.77769%201.16602%206.99935C1.16602%2010.221%203.77769%2012.8327%206.99935%2012.8327Z'%20stroke='%23666666'%20stroke-linecap='round'%20stroke-linejoin='round'/%3e%3cpath%20d='M1.16602%207H12.8327'%20stroke='%23666666'%20stroke-linecap='round'%20stroke-linejoin='round'/%3e%3cpath%20fill-rule='evenodd'%20clip-rule='evenodd'%20d='M6.99935%2012.8327C8.28802%2012.8327%209.33268%2010.221%209.33268%206.99935C9.33268%203.77769%208.28802%201.16602%206.99935%201.16602C5.71068%201.16602%204.66602%203.77769%204.66602%206.99935C4.66602%2010.221%205.71068%2012.8327%206.99935%2012.8327Z'%20stroke='%23666666'%20stroke-linecap='round'%20stroke-linejoin='round'/%3e%3cpath%20d='M2.875%202.95898C3.93063%204.01461%205.38896%204.66754%206.99978%204.66754C8.61062%204.66754%2010.069%204.01461%2011.1246%202.95898'%20stroke='%23666666'%20stroke-linecap='round'%20stroke-linejoin='round'/%3e%3cpath%20d='M11.1246%2011.0425C10.069%209.98691%208.61062%209.33398%206.99978%209.33398C5.38896%209.33398%203.93063%209.98691%202.875%2011.0425'%20stroke='%23666666'%20stroke-linecap='round'%20stroke-linejoin='round'/%3e%3c/g%3e%3cdefs%3e%3cclipPath%20id='clip0_1267_9109'%3e%3crect%20width='14'%20height='14'%20fill='white'/%3e%3c/clipPath%3e%3c/defs%3e%3c/svg%3e)
An AC binds attributes (role, clearance, entitlement) to an identity; a PKC binds an identity to a key. They certify different claims.
The certificate that proves what you are, not who you are
A public-key certificate answers 'who is this key-holder?' — it binds an identity to a cryptographic key. An attribute certificate (AC) answers a different question: 'what is this person allowed to do?' It binds attributes — role, clearance, department, professional qualification, group membership — to an identity, and carries no public key of its own. The split is deliberate: identity changes rarely, authorisation changes often, and decoupling them lets a manager revoke someone's signing authority without re-issuing who they are. In signature workflows, attribute certificates are how a system can prove that the person who signed had the authority to sign.
At a glance
Five facts that cover most attribute-certificate questions.
ACs are issued by Attribute Authorities (AAs), which can be separate from the Certificate Authority that issues the identity.
Short lifetimes are normal and intentional — authorisation should expire faster than identity, making revocation rare-by-design.
The classical standard is RFC 5755 (PKIX attribute certificate profile); modern implementations often use JSON-based OAuth/OIDC tokens for similar purposes.
In signing workflows, ACs power role-based approval routing: the signature is valid because the signer's role entitlement is independently provable.
Attribute certificate vs public-key certificate
Two different claims, two different lifecycles.
| Attribute certificate (AC) | Public-key certificate (PKC) | |
|---|---|---|
| Binds | Attributes (roles, entitlements) to an identity | An identity to a public/private key pair |
| Issuer | Attribute Authority (AA) | Certificate Authority (CA) |
| Typical lifetime | Hours to days — short by design | Months to years |
| Contains a key | No | Yes — that is its whole point |
| Revocation pressure | Low — expiry outruns most revocation needs | High — key compromise must be revoked immediately |
| Signature-workflow role | Proves the signer was authorised (role, mandate) | Proves the document was signed by that identity's key |
Where attribute certificates appear in practice
Three settings where the AC pattern is quietly doing authorisation work.
Role-based signing authority
An enterprise signing gateway may require that every approval signature is accompanied by proof the signer holds the relevant role at signing time. The AC (or its modern token equivalent) supplies that proof, verified against the Attribute Authority rather than guessed from a directory lookup.
Qualified seals with mandate evidence
When an organisation's electronic seal is applied by an employee acting under delegated authority, some workflows attach attribute evidence showing the mandate. Under eIDAS-style thinking, the seal proves the organisation's integrity; the mandate evidence connects it to the human decision.
Modern equivalents: OAuth scopes and verifiable credentials
The industry largely implements the AC pattern today as OAuth 2.0 scopes in access tokens, or — increasingly — as W3C verifiable credentials carrying role or qualification claims, includable in digital-wallet flows under eIDAS 2.0. The abstraction survives; the encoding moved on from CMS structures.
Why e-signature buyers should care
Authorisation is the half of signing governance most platforms undersell.
Ask how signing authority is proven
When a supplier agreement is executed, can the platform evidence that the signer held procurement authority on that date — from an independent authority, not just a directory screenshot? Role-entitlement evidence at signing time is the difference between a defensible and an arguable approval chain.
Expiry is a feature for compliance
Short-lived authorisation means yesterday's approver cannot silently sign today. If your workflow uses long-lived role grants with no time-bound evidence, you have the revocation problem ACs were designed to avoid.
Audit trails should capture both claims
A complete evidence package records the identity claim (who signed, authenticated how) and the authorisation claim (what entitled them). Tools that capture only the first leave internal-fraud and 'exceeded mandate' disputes unanswered.
Common questions
No. An AC contains no signing key — it cannot sign anything. It can be presented alongside a signature made with a PKC-bound key, as evidence that the key-holder was authorised at that moment.
