5 聲明（Claims） 這一節說明客戶端如何獲取關於終端用戶聲明和驗證事件。它還定義了一組標準的基本聲明配置。預定義一組可請求的聲明，使用特定的scope值或能用於請求參數中的個人聲明。聲明可以直接來自OpenID提供者或分散式來源。 5.1 標準聲明（Standard Claims） 這個規範定 ...
5 聲明（Claims）
這一節說明客戶端如何獲取關於終端用戶聲明和驗證事件。它還定義了一組標準的基本聲明配置。預定義一組可請求的聲明，使用特定的scope值或能用於請求參數中的個人聲明。聲明可以直接來自OpenID提供者或分散式來源。
5.1 標準聲明（Standard Claims）
這個規範定義了一組標準的聲明。他們可以請求的返回或用戶信息的響應，此在 5.3.2節或在第二節中的ID Token。
sub string
在發行人終端用戶的主體標識符。
name string
終端用戶的全名，顯示的形式包括所有名稱部分，可能包括標題和尾碼,根據終端用戶的區域設置和偏好排序。
given_name string
名字(s)或終端用戶的名字(s)。註意,在一些文化中,人們可以有多個名字; 都可以存在,名字被空格字元分開。
family_name string
姓(s)或終端用戶的姓(s)。註意,在一些文化中,人們可以有多個家庭的名字或沒有姓; 都可以存在,名字被空格字元分開。
middle_name string
終端用戶的中間名(s)。註意,在一些文化中,人們可以有多個中間的名字; 都可以存在,名字被空格字元分開。還要註意,在一些文化中,中間的名字存在。
nickname string
終端用戶的昵稱可能是也可能不是與 given_name相同。例如,邁克的昵稱可能是邁克爾的 given_name。
preferred_username string
簡寫名稱由終端用戶希望在RP中參考,如 janedoe 或 j.doe 。這個值可以是任何有效的JSON字元串包括等特殊字元 @ ,/或空格。RP不能要求這個值是獨一無二的，此在 5.7節 討論。
profile string
終端用戶的概要文件頁面的URL。這個Web頁面的內容應該是關於終端用戶的。
picture string
終端用戶的概要文件的URL。這個URL必須引用一個圖像文件 (例如,一個PNG、JPEG或GIF圖像文件)，而不是包含圖像的Web頁面。註意,這個URL應該具體參考概要文件終端用戶的照片，適合顯示在終端用戶描述中，而不是由用戶任意拍照。
website string
URL的終端用戶的網頁或博客。這個網頁應該包含終端用戶發佈的信息 或表示終端用戶隸屬於一個組織。
email string
終端用戶的首選電子郵件地址。其值必須符合 RFC 5322 addr-spec語法。RP不能信任這個值是獨一無二的，此在 5.7節討論。
email_verified boolean
True,如果終端用戶的電子郵件地址已經驗證,否則為false。當這個聲明值為真,這意味著OP採取了積極的措施，確保這個電子郵件地址在執行驗證時是由用戶控制的。驗證電子郵件地址的方法是上下文相關的，依賴於信任框架或操作者的合同協議。
gender string
終端用戶的性別。值定義為女或男。當兩個定義值都不適用時，可以使用其他值。
birthdate string
終端用戶的生日，表示為一個 ISO 8601:2004 [ISO8601 - 2004] YYYY-MM-DD 格式。年可能是 0000年 ，這表明它是省略了。僅呈現年，YYYY 格式是允許的。請註意，根據底層平臺的日期相關的功能，僅提供年可能導致不同的月和日，實現者需要考慮這個因素，以正確處理日期。
zoneinfo string
字元串，從zoneinfo (zoneinfo) 時區數據代表終端用戶的時區。例如，歐洲/巴黎 或 美國/洛杉磯。
locale string
終端用戶的語言環境,表示為 BCP47 [RFC5646]語言標簽。通常是一個 ISO 639-1 Alpha-2 [ISO639 - 1] 語言代碼的小寫字母和一個 ISO 3166-1 Alpha-2[ISO3166 - 1] 的大寫國家代碼,由一個破折號。例如，en-US 、fr-CA.。相容性註意：有些使用的是下劃線作為分隔符,而不是一個破折號,例如，en_US 依賴方，可以選擇接受這種語言的語法。
phone_number string
終端用戶首選的電話號碼。E.164 (E.164) 建議格式的聲明，例如，+ 1(425)555-1212 或 +56 (2) 687 2400。如果電話號碼包含一個擴展,建議使用表示 RFC 3966 [RFC3966]擴展語法，例如，+1 (604) 555-1234;ext=5678。
phone_number_verified boolean
True，如果終端用戶的電話號碼被驗證；否則false。當這個值為真時，意味著OP採取了積極的措施確保這個電話號碼是由用戶控制的執行驗證。驗證電話號碼方式是上下文相關的，依賴於信任框架或操作者的合同協議。當為真時，phone_number 聲明必須在E.164格式和任何擴展必須在RFC 3966格式表示。
address JSON object
終端用戶的首選郵政編碼。地址一個JSON (RFC4627) 結構，包含部分或全部5.1.1節中定義的成員 。
updated_at number
最後一次終端用戶更新時間的信息。它的值是一個JSON的數字代表的秒數 1970 - 01 - 01 T0:0:0Z UTC,以來的日期/時間來衡量。
5.1.1 地址聲明（Address Claim）
地址聲明代表一個實際郵寄地址。其實現時，可能只返回的一個子集，一個地址部分信息 ,這取決於信息可用性和終端用戶的隱私偏好。例如，可能不會返回更細粒度的國家和地區地址信息。
實現可能僅返回一個單獨字格式化字串的完整的地址，或者他們可能會返回單個組件，使用其他的子欄位,欄位 或者他們可能返回的。如果兩個變體都返回，他們應該描述的是相同的地址,格式化指示如何處理組件欄位組合。
formatted
完整的郵寄地址，格式化顯示或使用郵件標簽。這個欄位可能包含多個行,以換行隔開。換行可以表示為一對回車/換行(“\ r \ n”)或一個換行字元(“\ n”)。
street_address
完整的街道地址的組件，其中可能包括門牌號、街道名稱、 郵政信箱，多行擴展的街道地址信息。這個欄位可能包含多個行，以換行隔開。換行可以表示為一對回車/換行(“\ r \ n”)或一個換行字元(“\ n”)。
locality
本地化：城市或本地組件。
region
區域：國家,省，縣或地區組件。
postal_code
郵政編碼或郵政編碼組件。
country
國家名稱組件。
5.1.2 附加聲明（Additional Claims）
雖然本規範僅將一小部分聲明定義為標準聲明，其他聲明可以與標準聲明一起使用。當使用這樣的聲明，建議 collision-resistant名稱用於聲明的名字，如JSON Web Token(JWT) JWT規範中描述的那樣。另外， 在JWT規範中所描述的命名不太可能出現衝突時，私有的聲明可以安全地使用。或者,如果特定的附加聲明將有廣泛和普遍適用性，則可以根據JWT規範以註冊聲明那樣進行註冊。
5.2聲明語言和腳本（Claims Languages and Scripts）
人類可讀的聲明值和參照人類可讀聲明值，可能出現在多種語言和腳本中。對於特定語言和腳本，BCP47 [RFC5646]語言被添加到成員的名字標簽，由一個分隔開的 # 的風格。例如，family_name # ja-Kana-JP 表達了日本的姓名中片假名，常用的索引並代表相同的漢字的語音表示，表示為 family_name # ja-Hani-JP 。另外一個可能會返回值例子： website and website#de聲明，表明為一個未指明的語言網站和一個德國網站。
因為名稱區分大小寫，強烈推薦，語言中使用的標記值名稱拼寫使用要求風格與他們註冊的IANA語言標記註冊表 [IANA.Language]一致。特別的，通常語言名稱用小寫字母拼寫，地區名稱以大寫字元拼寫，腳本是拼寫和大小寫混合字元。然而,由於BCP47語言標簽值區分大小寫，實現應該解釋語言以區分大小寫的方式提供的標簽值。
按照BCP47的建議,主張語言標簽值只應根據具體需要。例如,使用 fr 可能就足夠了，在許多情況下,而不是 fr-CA或 fr-FR。在可能的情況下，OPs應該儘量匹配要求聲明地區聲明。例如,如果客戶要求聲明一個de (德國)語言標簽和OP有一個值標記 de-CH (瑞士德語)不是一般意義上的德國，它將適合OP 瑞士德語值返回給客戶機。(這有意移動標記語言的複雜性，OP儘可能匹配，簡化客戶。)
OpenID Connect定義了以下授權請求參數，通過返回的聲明激活特定的首選語言和腳本：
claims_locales
可選的。終端用戶的首選語言和腳本返回，表示為一個空格分隔的列表 BCP47 RFC5646語言標記值,按偏好排序。如果OpenID提供者不支持一些或所有的請求的區域設置應該返回錯誤。
當OP決定通過 claims_locales 參數，或通過其他方式,終端用戶和客戶 請求聲明只有一組語言和腳本，建議當他們使用這個語言和腳本，OPs回報沒有語言標簽聲明。也建議以客戶書面的方式說明他們可以處理和利用聲明使用語言標記。
5.3 用戶信息終結點(UserInfo Endpoint)
用戶信息的終結點是返回關於驗證用戶的OAuth 2.0受保護資源。獲得關於終端用戶的請求,客戶端發出請求的用戶信息通過OpenID Connect驗證的Access Token至終結點。這些聲明通常是一個JSON對象,其中包含表示聲明的名稱和值對集合。
用戶信息終結點通信必須使用TLS。參看 16.17節關於使用TLS的更多信息。
用戶信息的終結點必須支持的使用RFC 2616 [RFC2616]中定義的HTTP GET 和 HTTP POST 方法。
用戶信息的終結點必須接受使用如OAuth 2.0無記名令牌的Access Token [RFC6750]。
UserInfo終結點應該支持使用跨源資源共用(CORS)和或其他方法使Java腳本客戶能訪問終結點。
5.3.1 用戶信息請求（UserInfo Request）
客戶端使用 HTTP GET 或HTTP POST發送用戶信息請求。OpenID Connect 驗證的請求獲得的Access Token必須被作為持票人令牌發送（OAuth 2.0無記名令牌用法 [RFC6750]）。
建議請求使用 HTTP GET 方法和使用授權頭欄位發送Access Token。
下麵是一個非規範化用戶信息請求的例子:
GET /userinfo HTTP/1.1
Host: server.example.com
Authorization: Bearer SlAV32hkKG
5.3.2 成功的用戶信息的響應（Successful UserInfo Response）
UserInfo聲明必須返回一個JSON對象的成員，除非在客戶機註冊期間請求簽名或加密響應。定義在5.1節聲明可以返回，並可以有沒有指定的額外聲明。
出於隱私原因，OpenID提供者可能選擇不返回某些請求聲明。
如果不返回聲明，聲明的名字應當省略其在JSON對象中代表的聲明，不應出現一個null或空字元串。
sub(Subject)聲明包含在用戶信息的響應中，必須始終返回。
註意:由於令牌替換攻擊的可能性 (見 16.11節 )，用戶信息的響應是沒有保證的，終端用戶確定的 sub(Subject) 元素的ID Token。在用戶信息響應的sub必須驗證，並完全匹配於ID Token的sub； 如果它們不匹配，就不能使用用戶信息的響應值。
在收到用戶信息請求，用戶信息終結點必須返回13.3節中HTTP響應body，並JSON序列化響應的用戶信息，除非在註冊過程中指定不同的格式 (OpenID.Registration) 。用戶信息的終結點必須返回一個內容類型頭來表示返回格式。HTTP響應必須的內容類型 application/json 如果body的響應是一個文本JSON對象； body應該使用UTF-8編碼的響應。
如果用戶信息的響應 簽名和/或加密，那麼聲明JWT和返回內容類型必須是application/jwt。響應可能加密也沒有被簽名。如果兩個簽名和加密請求，響應必須簽名然後加密，結果是一個嵌套JWT 。
如果簽名，用戶信息的響應應該包含聲明 iss (發行人) 和 aud (消費者)成員。iss 值應該是OP的發佈者標識符的URL。aud 值應該是或包括RP的客戶機ID值。
下麵是一個非規範化用戶信息的響應的例子：
HTTP/1.1 200 OK
Content-Type: application/json
{
"sub": "248289761001",
"name": "Jane Doe",
"given_name": "Jane",
"family_name": "Doe",
"preferred_username": "j.doe",
"email": "[email protected]",
"picture": "http://example.com/janedoe/me.jpg"
}
5.3.3 用戶信息錯誤響應(UserInfo Error Response)
當發生一個錯誤條件時，用戶信息終結點的返回錯誤響應在OAuth 2.0 Bearer Token Usage [RFC6750]第三節中定義。和RFC 6750(HTTP錯誤返回給用戶代理使用適當的HTTP狀態碼。)
下麵是一個非規範化用戶信息錯誤的響應的例子：
HTTP/1.1 401 Unauthorized
WWW-Authenticate: error="invalid_token",
error_description="The Access Token expired"
5.3.4 用戶信息響應確認（UserInfo Response Validation）
客戶端必須驗證用戶信息的響應如下:
1、驗證OP響應是OP 通過TLS伺服器證書檢查,遵循RFC 6125 [RFC6125]。
2、如果客戶在註冊期間提供了 userinfo_encrypted_response_alg 參數，用指定的在註冊過程中的鍵對用戶信息進行解密的響應。
3、如果響應簽名,客戶端應該根據簽名驗證jws。
5.4 請求聲明使用的scope值（Requesting Claims using Scope Values）
OpenID Connect客戶端使用範圍值，在OAuth 2.0 (RFC6749) 3.3節中定義，指定正在請求具有什麼訪問許可權的Access Token。相關的範圍指定Access Token確定哪些用於訪問OAuth 2.0保護終結點可用的資源。使用請求Access Token，受保護的資源終結點可能執行不同的動作和基於scope值和其他參數時返回不同的信息。
OpenID Connect，scopes可用於要求特定的可用聲明信息集。
授權伺服器聲明請求的以下scopes聲明。
OpenID Connect定義如下請求聲明範圍：
profile
可選的。scope值請求訪問終端用戶的預設的配置,他們是：name，family_name，given_name，middle_name，nickname，preferred_username，profile，picture，website，gender，birthdate，zoneinfo，locale，and updated_at。
可選的。scope值訪問請求的電子郵件和email_verified聲明。
address
可選的。scope值訪問請求的地址聲明。
phone
可選的。scope的 phone_number 和 phone_number_verified 聲明。
多個scope值可以通過空隔符分隔，並且是大小敏感的ASCII scope值。
用於聲明請請求的profile, email, address, and phone，用戶信息的終結點返回的scope，在 5.3.2節中描述 ，當使用一個發佈的Access Token結果中的 response_type 值。然而，當沒有Access Token (這種情況 response_type 值是id_token )，聲明結果將從ID Token中返回。
在某些情況下，終端用戶將選擇婉拒OpenID提供者提供部分或全部RPs請求信息。以最少量信息公開給終端用戶請求，RP只能選擇從用戶終結點請求可用信息的子集。
下麵是一個非規範化未編碼scope請求的例子:
scope=openid profile email phone
5.5 使用“聲明”請求參數的請求聲明（Requesting Claims using the "claims" Request Parameter）
OpenID Connect定義了以下可用的獨立聲明的授權請求參數，並指定適用於請求聲明參數：
claims
可選的。這個參數是用來返回特定請求聲明。其值是一個請求聲明的JSON對象列表。
聲明驗證請求參數要求特定被用戶信息返回的終結點和/或ID Token。它表示為JSON對象，包含從這些位置的聲明請求列表，請求的聲明屬性也可以指定。
對聲明參數的支持是可選的。如果OP不支持這個參數，並且RP使用它，OP應該向RP返回一組聲明，它認為這些聲明對RP和最終用戶有用，並使用它認為合適的啟髮式方法。 claims_parameter_supported發現結果指示OP是否支持此參數。
聲明參數值，表示為OAuth 2.0請求的UTF-8編碼加密的JSON (最終被form-urlencoded當作為一個OAuth參數傳遞)。請求對象中使用值，是在 定義在6.1節，JSON用作聲明成員的值。。
頂級聲明請求JSON對象的成員有：
userinfo
可選的。要求列出從用戶信息的終結點返回的個人聲明。如果存在,聲明列表被要求添加任何聲明被使用scope值請求。如果不存在,則聲明從用戶信息請求的終結點，只有那些要求使用的scope值。
當使用用戶信息成員，請求必須使用 response_type 值,結果在一個被使用用戶信息的終結點發佈到客戶機的Access Token。
id_token
可選的。要求列出返回ID Token的個人聲明。如果存在,聲明列表被請求添加至預設ID Token預設聲明。如果不存在,則預設ID Token聲明請求，根據第二節ID Token定義和每個附加流程中3.1.3.6、3.2.2.10、3.3.2.11 、3.3.3.6的ID Token要求。
可能存在其他成員。必須忽略使用任何不理解的成員。
聲明請求一個例子如下:
{
"userinfo":
{
"given_name": {"essential": true},
"nickname": null,
"email": {"essential": true},
"email_verified": {"essential": true},
"picture": null,
"http://example.info/claims/groups": null
},
"id_token":
{
"auth_time": {"essential": true},
"acr": {"values": ["urn:mace:incommon:iap:silver"] }
}
}
請註意,聲明不是標準中定義的設置 （5.1節 (例子)） http://example.info/claims/groups 聲明，被請求。使用聲明參數僅令是請求聲明以外的標準設置的方法。也是請求標準聲明不能使用範圍指定值的特定組合的唯一途徑。
5.5.1 個人聲明請求(Individual Claims Requests)
用戶信息和id_token聲明成員，都是JSON對象請求，個人聲明的名字被請求作為成員的名字。成員的值必須是下列之一：
null
表明,這種聲明被要求以預設方式。特別是,這是一個自願協議聲明。例如,聲明請求:
"given_name": null
以預設的方式請求 given_name 聲明。
JSON Object
用於提供關於附加信息請求的聲明。本規範定義了以下成員：
essential
可選的。指示是否被請求聲明是一個重要的聲明。如果該值為真 ，表明聲明是一個重要的聲明。例如，聲明請求:
"auth_time": {"essential": true}
特指返回auth_time 聲明是很重要的。
如果該值為false ，表明這是一個自動的聲明。預設值是false 。
通過請求聲明作為必要的聲明，RP指示終端用戶，允許發表這些聲明，確保終端用戶要求的特定任務順利授權。註意，即使沒有因為終端用戶中沒有授權發佈或不存在，當聲明無返回，授權伺服器不能產生一個錯誤，如果他們是必要或自動的，除非另有說明對於特定要求的描述。
value
可選的。請求聲明返回特定值。例如聲明請求:
"sub": {"value": "248289761001"}
可用於指定請求適用於終端用戶附加Subject標識符 248289761001 。
value成員值必須是一個有效的聲明請求。個人聲明的定義，可以包含要求如何以及是否 value 限定符是用於聲明請求。
values
可選的。請求聲明返回一組值中的一個，values以優先順序排列出現。例如聲明請求:
"acr": {"essential": true,
"values": ["urn:mace:incommon:iap:silver",
"urn:mace:incommon:iap:bronze"]}
指定是十分必要的。acr聲明返回 "urn:mace:incommon:iap:silver", "urn:mace:incommon:iap:bronze"之一。
values 數組成員，必須是有效的聲明請求值。個人聲明的定義可以包含要求如何以及是否values限定符是用於當要求聲明。
其他成員可能會提供額的關於請求聲明的信息。必須忽略使用任何不能理解的成員。
註意,當聲明請求參數支持,請求聲明scope值,定義在 5.4節 有效地簡化個人請求的方式。例如,使用scope值 openid的email 和response_type 返回一個Access Token，相當於使用scope值 openid 和如下個人聲明請求。
相當於使用 email的 scope值:
{
"userinfo":
{
"email": null,
"email_verified": null
}
}
5.5.1.1 “acr”請求聲明（Requesting the "acr" Claim）
如果 acr 聲明請求作為ID Token基本聲明，此令牌有values參數，並要求特定的驗證上下文類值和引用實現支持聲明參數，授權伺服器必須返回一個 acr 聲明值中相匹配請求的值中的一個。授權伺服器可以要求終端用戶使能滿足需求的附加條件重新認證。如果這是一個重要的聲明和需求無法滿足，則授權伺服器必須以驗證未遂不成功來對待。
註意，RP請求 acr 聲明作為一個自願的聲明，以使用 acr_values 請求參數或不包括“essential”：在一個獨立的個體 acr 聲明請求。如果聲明是非基本的和不能提供請求值,授權伺服器應該返回當前會話的 acr 作為acr聲明值。如果聲明不是必須的，授權伺服器不需要提供這一聲明響應。
如果客戶機同時使用 acr_values 請求參數和一個個人acr聲明（ID Token清單中特定請求值），請求 acr 聲明，產生的行為是不確定的。
5.5.2 個人聲明的語言和腳本（Languages and Scripts for Individual Claims）
如5.2節中描述的， 可讀的聲明值和聲明值引用可讀的值，可以用多種語言和腳本。在個人聲明請求，要求特定的聲明可能包括聲明請求的名稱語言和腳本，包含 #-separated BCP47 [RFC5646]語言的聲明請求標簽 ,使用5.2節聲明中指定名稱的語法 。例如，可以使用Name聲明 family_name#ja- jp 請求日語片假名中的姓，也可以使用Name聲明 family_name#ja-Hani-JP請求日語中該姓的漢字表示。可以使用Name聲明website#de請求德語網站。
如果OP接收到它沒有的可讀的聲明請求的語言和腳本，則返回的那些聲明的任何版本，如果不使用所請求的語言和腳本，則應該在聲明名稱中使用語言標記。
5.6 聲明類型（Claim Types）
該規範定義的三種聲明表象值是：
Normal Claims（標準聲明）
OpenID提供者直接定義的聲明。
Aggregated Claims（聚合的聲明）
OpenID提供者以外的聲明提供值者定義，但由OpenID提供者返回的。
Distributed Claims（分散式聲明）
OpenID提供者以外的聲明提供值者定義，但由OpenID提供者參照返回的。
標準聲明必須支持。聚合聲明和分散式聲明的支持是可選的。
5.6.1標準聲明（Normal Claims）
標準聲明表示為JSON對象的成員。聲明的名字是成員名和值是成員的值。
下麵是一個非規範化包含標準聲明響應:
{
"name": "Jane Doe",
"given_name": "Jane",
"family_name": "Doe",
"email": "[email protected]",
"picture": "http://example.com/janedoe/me.jpg"
}
5.6.2 聚合和分散式聲明(Aggregated and Distributed Claims)
聚合和分散式聲明使用特殊的 _claim_names 和 _claim_sources 成員包含聲明的JSON對象表示。
_claim_names
JSON對象的成員名字是聲明聚合的名稱和分佈聲明。_claim_sources 的成員值引用成員名字，實際可以檢索的聲明值。
_claim_sources
JSON對象的_claim_names 成員名稱引用的成員的值。成員的值包含組聚合聲明或參考本地化分散式聲明。成員可以有一個以下格式的值，取決於是否提供聚合或分散式聲明：
Aggregated Claims
JSON對象必須包含 JWT成員，此成員必須包含所有的在 _claim_names 對象引用和相應的 _claim_sources 成員的聲明。也可能存在其他成員。必須忽略使用的任何不理解的成員。
JWT
必需的。JWT包含值。
JWT不應該包含一個 sub(Subject) 聲明，除非它的值是一個標識符為終端用戶聲明提供者(而不是為OpenID提供者或另一方)；這通常意味著不應該被提供一個sub聲明。
Distributed Claims
JSON對象，包含以下成員和值:
endpoint
必需的。OAuth 2.0資源關聯的聲明可以檢索的終結點。終結點URL必須以JWT聲明返回。
access_token
可選的。Access Token可以通過使用 OAuth 2.0無記名令牌用法 (RFC6750) 協議從終結點URL檢索的聲明。聲明應該要求使用授權請求頭欄位和聲明供應者必須支持的方法。如果Access Token不可用, RPs可能需要檢索Access Token之外的或使用一個提供者和RP之間預先商談好的Access Token,或聲明提供者可能重認證的 終端用戶和/或RP重新授權。
一個 sub(Subject)聲明不應該從提供者返回，除非它的值是一個標識符為終端用戶聲明提供者(而不是為OpenID提供者或另一方); 這通常意味著不應該被提供一個sub聲明。
一般來說，當OP時適當使用聚合聲明和分散式聲明。在某些情況下,使用的聲明信息類型可能是RPs 和OPs另外協商好的。
5.6.2.1 聚合聲明例子（Example of Aggregated Claims）
在這個非規範化的例子中,聲明從聲明供應者A結合其他聲明持有的OpenID提供者, 聲明從聲明供應者A作為聚合聲明返回。
在這個例子中,這些關於Jane Doe已簽發聲明提供者A:
{
"address": {
"street_address": "1234 Hollywood Blvd.",
"locality": "Los Angeles",
"region": "CA",
"postal_code": "90210",
"country": "US"},
"phone_number": "+1 (310) 123-4567"
}
聲明提供A簽名了JSON聲明,代表他們簽名了JWT: jwt_header.jwt_part2.jwt_part3。這正是OpenID提供者使用的JWT。
在這個例子中,這個JWT包含Jane Doe的從聲明供應商A結合其他標準聲明的聚合聲明，並返回以下的聲明設置:
{
"name": "Jane Doe",
"given_name": "Jane",
"family_name": "Doe",
"birthdate": "0000-03-22",
"eye_color": "blue",
"email": "[email protected]",
"_claim_names": {
"address": "src1",
"phone_number": "src1"
},
"_claim_sources": {
"src1": {"JWT": "jwt_header.jwt_part2.jwt_part3"}
}
}
5.6.2.2分散式聲明的例子（Example of Distributed Claims）
在這個非規範化的例子中,OpenID提供者結合它擁有對引用的聲明來自兩個不同的聲明供應商,B和C的標準聲明,將來自於B和C的聲明合併引用為分佈聲明。
在這個例子中, 由提供者B持有的關於Jane Doe持有的聲明(Jane Doe的銀行):
{
"shipping_address": {
"street_address": "1234 Hollywood Blvd.",
"locality": "Los Angeles",
"region": "CA",
"postal_code": "90210",
"country": "US"},
"payment_info": "Some_Card 1234 5678 9012 3456",
"phone_number": "+1 (310) 123-4567"
}
同樣在這個例子中, 由提供者C持有的關於Jane Doe(信貸機構):
{
"credit_score": 650
}
OpenID提供者返回Jane Doe的隨著引用了提供者B和C兩個聲明提供者的聲明，通過發送的Access Token及分散式聲明可以檢索的URLs位置:
{
"name": "Jane Doe",
"given_name": "Jane",
"family_name": "Doe",
"email": "[email protected]",
"birthdate": "0000-03-22",
"eye_color": "blue",
"_claim_names": {
"payment_info": "src1",
"shipping_address": "src1",
"credit_score": "src2"
},
"_claim_sources": {
"src1": {"endpoint":
"https://bank.example.com/claim_source"},
"src2": {"endpoint":
"https://creditagency.example.com/claims_here",
"access_token": "ksj3n283dke"}
}
}
5.7 聲明的穩定性和唯一性（Claim Stability and Uniqueness）
sub(主題)和iss (發行人)聲明,一起使用， 成為唯一聲明，是RP可以依靠穩定的終端用戶標識符，因此sub聲明必須是本地獨特而從未在發行人為特定的用戶重新分配,如第二節中描述。因此,只有sub(主題)和iss (發行人)聲明保證給組合定用戶的惟一標識符。
其他所有的聲明對於不同的發行人而言,在用戶穩定時間和獨特性,並允許發佈者應用局部限制和策略上沒有此類擔保。例如,一個發行人可能重用一個 電子郵件聲明值給不同終端用戶，在不同的時間點，隨著時間的推移，電子郵件對於一個給定的用戶可能會改變地址。因此,諸如其他像電子郵件的聲明，phone_number ，preferred_username ,也不能作為終端用戶的惟一標識符。
