AC 把屬性(角色、權限、資格)繫結到身分;PKC 把身分繫結到金鑰。它們證明的是不同的主張。
證明「你能做什麼」而不是「你是誰」的憑證
公鑰憑證回答「這個金鑰持有人是誰?」——它把身分繫結到加密金鑰。屬性憑證(AC)回答另一個問題:「這個人被允許做什麼?」它把屬性——角色、權限、部門、職業資格、群組成員身分——繫結到身分,自身不攜帶任何公鑰。這個拆分是有意為之:身分很少變化,授權經常變化,解耦兩者讓管理者可以撤銷某人的簽署權限,而不必重新簽發「他是誰」。在簽署工作流程裡,屬性憑證就是系統能夠證明「簽署的人當時有權簽」的那套機制。
要點速覽
五個事實涵蓋大多數屬性憑證問題。
AC 由屬性機構(AA)簽發,AA 可以與簽發身分的憑證機構(CA)相互獨立。
短生命週期是常態也是設計意圖——授權應當比身分更快到期,讓吊銷幾乎不需要。
經典標準是 RFC 5755(PKIX 屬性憑證規範);現代實作常用 JSON 格式的 OAuth/OIDC 權杖達到類似目的。
在簽署工作流程裡,AC 支撐基於角色的審批路由:簽名有效,因為簽署人的角色資格可被獨立證明。
屬性憑證與公鑰憑證
兩種不同的主張,兩種不同的生命週期。
| 屬性憑證(AC) | 公鑰憑證(PKC) | |
|---|---|---|
| 繫結內容 | 屬性(角色、權限、資格)到身分 | 身分到一對公私鑰 |
| 簽發者 | 屬性機構(AA) | 憑證機構(CA) |
| 典型有效期 | 數小時到數天——設計上就短 | 數月到數年 |
| 是否包含金鑰 | 否 | 是——這正是它的意義 |
| 吊銷壓力 | 低——到期速度跑贏絕大多數吊銷需求 | 高——金鑰外洩必須立即吊銷 |
| 在簽名流程中的角色 | 證明簽署人被授權(角色、授權範圍) | 證明文件由該身分的金鑰簽署 |
屬性憑證在實務中出現在哪裡
AC 模式安靜地承擔授權工作的三個場景。
基於角色的簽署權限
企業簽署閘道可以要求每個審批簽名都附帶證明:簽署人在簽署當時持有相關角色。AC(或其現代權杖等價物)提供這一證明,向屬性機構核驗,而不是靠目錄查詢猜。
帶授權證據的合格印章
當機構的電子印章由員工在授權範圍內加蓋時,一些工作流程會附上顯示授權範圍的屬性證據。按 eIDAS 的思路:印章證明機構完整性;授權證據把它連結到人的決策。
現代等價物:OAuth scope 與可驗證憑證
業界如今大多把 AC 模式實作為存取權杖中的 OAuth 2.0 scope,或者——越來越多地——承載角色或資格主張的 W3C 可驗證憑證,可納入 eIDAS 2.0 的數位錢包流程。抽象概念存活了下來;編碼方式已從 CMS 結構演進。
電子簽名買家為什麼應該在意
授權是簽署治理中被多數平台低估的那一半。
問簽署權限如何被證明
當供貨協議被執行時,平台能否證明簽署人在該日期持有採購權限——來自獨立機構,而不是一張目錄截圖?簽署時的角色資格證據,是可辯護與可爭辯審批鏈的區別。
到期對合規是特性
短時效授權意味著昨天的審批人無法在今天悄悄簽字。如果你的工作流程使用長期有效的角色授予且沒有帶時間邊界的證據,你就遇到了 AC 設計上要避免的吊銷問題。
稽核軌跡應同時記錄兩種主張
完整的證據包記錄身分主張(誰簽的、如何認證)和授權主張(憑什麼資格)。只記錄前者的工具,在內部舞弊和「越權簽署」爭議面前無從回應。
常見問題
不能。AC 不包含簽署金鑰——它簽不了任何東西。它可以與用 PKC 繫結金鑰產生的簽名一起出示,作為金鑰持有人當時被授權的證據。







