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。

email

可選的。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 ,也不能作為終端使用者的惟一識別符號。