OpenID Connect Core 1.0（九）聲明(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": "janedoe@example.com",

   "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）

客戶端必須驗證用戶信息的響應以下:

一、驗證OP響應是OP 經過TLS服務器證書檢查,遵循RFC 6125 [RFC6125]。

二、若是客戶在註冊期間提供了 userinfo_encrypted_response_alg 參數，用指定的在註冊過程當中的鍵對用戶信息進行解密的響應。

三、若是響應簽名,客戶端應該根據簽名驗證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.六、3.2.2.十、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": "janedoe@example.com",

   "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": "janedoe@example.com",

   "_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": "janedoe@example.com",

   "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 ,也不能做爲終端用戶的唯一標識符。