概述
JSON Web令牌（JWT）是一個緊湊的采用URL安全表示方法的聲明，用于在兩方之間傳輸。JWT的聲明被編碼為一個JSON對象，作為一個JSON Web Signature（JWS）結(jié)構(gòu)的有效載荷或作為一個JSON Web Encryption（JWE）結(jié)構(gòu)的明碼文本，允許聲明被數(shù)字簽名和進行完整性檢查，通過消息認證碼（MAC）或者加解密。
備忘錄狀態(tài)
這是一個因特網(wǎng)標(biāo)準(zhǔn)跟蹤文檔。
本文檔是互聯(lián)網(wǎng)工程任務(wù)組（IETF）的產(chǎn)品。它代表了IETF社區(qū)的共識。已獲得公眾意見審查，并獲準(zhǔn)由互聯(lián)網(wǎng)工程指導(dǎo)小組（IESG）出版。有關(guān)因特網(wǎng)標(biāo)準(zhǔn)的更多信息，請參考RFC 5741第二節(jié)
版權(quán)聲明
Copyright (c) 2015 IETF Trust和認證的文檔作者。版權(quán)所有。
1 介紹
JSON Web令牌（JWT）是一種緊湊的聲明表示格式，適用于空間受限的環(huán)境，如HTTP授權(quán)標(biāo)頭和URI查詢參數(shù)。JWT的聲明被編碼為一個JSON對象，作為一個JSON Web Signature（JWS）結(jié)構(gòu)的有效載荷或作為一個JSON Web Encryption（JWE）結(jié)構(gòu)的明碼文本，允許聲明被數(shù)字簽名和進行完整性檢查，通過消息認證碼（MAC）或者加解密。JWT總是使用JWS Compact Serialization或JWE Compact Serialization來表示。
JWT的建議發(fā)音與英文單詞“jot”相同。
1.1 公共標(biāo)識
關(guān)鍵字"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 和"OPTIONAL"將被解釋為“用于指示要求級別的關(guān)鍵詞”RFC2119描述的那樣。只有當(dāng)術(shù)語出現(xiàn)在所有大寫字母中時才應(yīng)用該解釋。
2 術(shù)語
"JSON Web Signature (JWS)", "Base64url Encoding", "Header Parameter", "JOSE Header", "JWS Compact Serialization", "JWS Payload", "JWS Signature", 和"Unsecured JWS"在JWS規(guī)范JWS里定義。
"JSON Web Encryption (JWE)", "Content Encryption Key (CEK)", "JWE Compact Serialization", "JWE Encrypted Key", 和"JWE Initialization Vector"在JWE規(guī)范JWE里定義。
"Ciphertext", "Digital Signature", "Message Authentication Code (MAC)", and "Plaintext"在"Internet Security Glossary, Version 2"RFC4949里定義。
這些術(shù)語由本說明書定義：
JSON Web Token (JWT)
A string representing a set of claims as a JSON object that is encoded in a JWS or JWE, enabling the claims to be digitally signed or MACed and/or encrypted.
JWT Claims Set
A JSON object that contains the claims conveyed by the JWT.
Claim
A piece of information asserted about a subject. A claim is represented as a name/value pair consisting of a Claim Name and a Claim Value.
Claim Name
The name portion of a claim representation. A Claim Name is always a string.
Claim Value
The value portion of a claim representation. A Claim Value can be any JSON value.
Nested JWT
A JWT in which nested signing and/or encryption are employed. In Nested JWTs, a JWT is used as the payload or plaintext value of an enclosing JWS or JWE structure, respectively.
Unsecured JWT
A JWT whose claims are not integrity protected or encrypted.
Collision-Resistant Name
A name in a namespace that enables names to be allocated in a manner such that they are highly unlikely to collide with other names. Examples of collision-resistant namespaces include: Domain Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and X.670 Recommendation series, and Universally Unique IDentifiers (UUIDs) [RFC4122]. When using an administratively delegated namespace, the definer of a name needs to take reasonable precautions to ensure they are in control of the portion of the namespace they use to define the name.
StringOrURI
A JSON string value, with the additional requirement that while arbitrary string values MAY be used, any value containing a ":" character MUST be a URI [RFC3986]. StringOrURI values are compared as case-sensitive strings with no transformations or canonicalizations applied.
NumericDate
A JSON numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds. This is equivalent to the IEEE Std 1003.1, 2013 Edition [POSIX.1] definition "Seconds Since the Epoch", in which each day is accounted for by exactly 86400 seconds, other than that non-integer values can be represented. See RFC 3339 [RFC3339] for details regarding date/times in general and UTC in particular.
3 JSON Web令牌（JWT）概述
JWT表示一組以JWS和/或JWE結(jié)構(gòu)編碼的JSON對象的聲明。 這個JSON對象是JWT聲明集。 根據(jù)RFC 7159 [RFC7159]的第4節(jié)，JSON對象由零個或多個名稱/值對（或成員）組成，其中名稱是字符串，值是任意的JSON值。 這些成員是由JWT代表的聲明。 根據(jù)RFC 7159 [RFC7159]的第2節(jié)，此JSON對象可能在任何JSON值或結(jié)構(gòu)字符之前或之后包含空格和/或換行符。
JWT聲明集中的成員名稱稱為聲明名稱。 相應(yīng)的值稱為聲明值。
JOSE標(biāo)題的內(nèi)容描述了應(yīng)用于JWT聲明集的加密操作。 如果JOSE標(biāo)頭用于JWS，則JWT被表示為JWS，聲明是數(shù)字簽名或MACed，JWT聲明集是JWS有效載荷。 如果JOSE標(biāo)頭用于JWE，則JWT被表示為JWE，聲明被加密，JWT聲明集是由JWE加密的明文。 JWT可以封裝在另一個JWE或JWS結(jié)構(gòu)中，以創(chuàng)建嵌套的JWT，從而實現(xiàn)嵌套簽名和加密。
JWT表示為由句點（'.'）字符分隔的URL安全部分的序列。 每個部分都包含一個base64url編碼的值。 JWT中的部件數(shù)量取決于使用JWS Compact Serialization或JWE使用JWE Compact Serialization的結(jié)果JWS的表示。
3.1 JWT示例
以下示例JOSE Header聲明編碼對象是JWT，JWT是使用HMAC SHA-256算法進行MACed的JWS：
{"typ":"JWT",
"alg":"HS256"}
為了消除上述JSON對象表示中的潛在模糊性，上面的JOSE標(biāo)頭在此示例中使用的實際UTF-8表示的八位字節(jié)序列也包含在下面。 （請注意，由于換行符（CRLF對LF）的不同平臺表示，行的開始和結(jié)束處的不同間距，最后一行是否具有終止換行符，以及其他原因，可能會導(dǎo)致模糊。 在這個例子中，第一行沒有前導(dǎo)或者后面的空格，在第一行和第二行之間出現(xiàn)一個CRLF換行符（13,10），第二行有一個前導(dǎo)空格（32），沒有尾隨空格，最后一行 沒有終止換行符。）在此示例中使用JOSE標(biāo)頭的UTF-8表示形式的八位字節(jié)（使用JSON數(shù)組符號）為：
[123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84, 34, 44, 13, 10,
32, 34, 97, 108, 103, 34, 58, 34, 72, 83, 50, 53, 54, 34, 125]
Base64url編碼JOSE頭的UTF-8表示的八位字節(jié)產(chǎn)生這個編碼的JOSE標(biāo)頭值：
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
以下是JWT聲明集的示例：
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
以下八位位組序列是JWT聲明集合在此示例中使用的UTF-8表示形式，是JWS有效載荷：
[123, 34, 105, 115, 115, 34, 58, 34, 106, 111, 101, 34, 44, 13, 10,
32, 34, 101, 120, 112, 34, 58, 49, 51, 48, 48, 56, 49, 57, 51, 56,
48, 44, 13, 10, 32, 34, 104, 116, 116, 112, 58, 47, 47, 101, 120, 97,
109, 112, 108, 101, 46, 99, 111, 109, 47, 105, 115, 95, 114, 111,
111, 116, 34, 58, 116, 114, 117, 101, 125]
編碼JWS有效載荷的Base64url產(chǎn)生這個編碼的JWS有效載荷（僅用于顯示目的）：
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly
9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ
使用HMAC SHA-256算法計算編碼的JOSE標(biāo)題的MAC和編碼的JWS有效載荷，并以[JWS]中指定的方式對HMAC值進行base64url生成此編碼的JWS簽名：
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
按照這個順序?qū)⑦@些編碼部分連接在部件之間的周期（'.'）字符之間產(chǎn)生這個完整的JWT（僅用于顯示目的）：
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
該計算在[JWS]的附錄A.1中有更詳細的說明。 有關(guān)加密JWT的示例，請參見附錄A.1。
4 JWT 聲明
JWT聲明集代表一個JSON對象，其成員是JWT傳達的聲明。 JWT聲明集中的聲明名稱必須是唯一的; JWT解析器必須拒絕具有重復(fù)的聲明名稱的JWT，或者使用JSON語法分析器，該語法僅返回最后一個重復(fù)的成員名稱，如ECMAScript 5.1 ECMAScript的第15.12節(jié)（“JSON對象”）中所述。
JWT必須包含被認為有效的一組聲明是上下文相關(guān)的，超出了本規(guī)范的范圍。 JWT的具體應(yīng)用將需要實現(xiàn)以特定方式理解和處理一些聲明。 然而，在沒有這樣的要求的情況下，實現(xiàn)中不了解的所有聲明必須被忽略。
有三類JWT索賠名稱：注冊索賠名稱，公開聲明名稱和私人聲明名稱。
4.1 注冊請求名稱
以下聲明名稱已注冊在由10.1節(jié)建立的IANA“JSON Web令牌聲明”注冊表中。 以下定義的所有權(quán)利要求都不意味著在所有情況下使用或?qū)嵤┦菑娭菩缘?，而是為一組有用的，可互操作的索賠提供了起點。 使用JWT的應(yīng)用程序應(yīng)該定義使用哪些特定聲明，何時需要或可選。 所有的名稱都很短，因為JWT的核心目標(biāo)是使其表現(xiàn)得很緊湊。
4.1.1 "iss" (Issuer) 聲明
"iss" (issuer) 請求確定發(fā)出JWT的委托人。 這種說法的處理通常是具體的應(yīng)用。 “iss”值是一個包含StringOrURI值的區(qū)分大小寫的字符串。 使用此聲明是可選的。
4.1.2 " sub" (Subject) 聲明
"sub" (Subject)請求確定作為JWT主題的委托人。JWT中的請求通常是關(guān)于該主題的陳述。 主體值必須在發(fā)行者的上下文中被限定為本地唯一的，或者是全局唯一的。 這種說法的處理通常是具體的應(yīng)用。 “sub”值是一個包含StringOrURI值的區(qū)分大小寫的字符串。 使用此聲明是可選的。
4.1.3 "aud" (Audience) 聲明
"aud" (audience)聲明識別JWT所針對的收件人。旨在處理JWT的每個主體都必須在受眾聲明中確定自己的價值。 如果索賠的主要處理在本聲明存在的情況下并未標(biāo)明“aud”索賠中的值，那么JWT必須被拒絕。 在一般情況下，“aud”值是一個區(qū)分大小寫的字符串?dāng)?shù)組，每個字符串都包含一個StringOrURI值。 在JWT有一個觀眾的特殊情況下，“aud”值可以是包含StringOrURI值的單個區(qū)分大小寫的字符串。 觀眾價值觀的解釋一般是具體的應(yīng)用。 使用此聲明是可選的。
4.1.4 "exp" (Expiration Time)請求
"exp" (expiration time)標(biāo)識JWT不得接受處理之前或之后的到期時間。處理"exp"請求要求當(dāng)前日期/時間必須在“exp”索賠中列出的到期日期/時間之前。實施者可能會提供一些小的余地，通常不超過幾分鐘來解決時鐘偏差。 其值必須是包含NumericDate值的數(shù)字。 使用此聲明是可選的。
4.1.5 "nbf" (Not Before) 請求
"nbf" (not before)請求標(biāo)識JWT不得接受處理的時間。處理“nbf”請求要求當(dāng)前日期/時間必須在“nbf”索賠中列出的未來日期/時間之前或之后。實施者可能會提供一些小的余地，通常不超過幾分鐘來解決時鐘偏差。其值必須是包含NumericDate值的數(shù)字。 使用此聲明是可選的。
4.1.6 "iat" (Issued At)請求
"iat"(issued at)請求確定發(fā)布JWT的時間。該索賠可用于確定JWT的年齡。 其值必須是包含NumericDate值的數(shù)字。 使用此聲明是可選的。
4.1.7 "jti" (JWT ID)請求
"jwi"(JWT ID)請求為JWT提供唯一的標(biāo)識符。必須以確保相同值被意外分配給不同數(shù)據(jù)對象的可能性很小的方式來分配標(biāo)識符值；如果應(yīng)用程序使用多個發(fā)行者，則必須在不同發(fā)行者產(chǎn)生的值之間防止沖突?！癹ti”請求可用于防止JWT重播。“jti”值是區(qū)分大小寫的字符串。 使用此聲明是可選的。
4.2 公開聲明名稱
4.3 私有聲明名稱
5 JOSE頭
5.1 "typ"(Type)頭參數(shù)
5.2 "cty"(Content Type)頭參數(shù)
5.3 復(fù)制請求作為頭參數(shù)
6 無擔(dān)保的JWT
為了支持JWT內(nèi)容通過除JWT內(nèi)的簽名和/或加密之外的方式來保護的用例（例如包含JWT的數(shù)據(jù)結(jié)構(gòu)上的簽名），JWT也可以在沒有簽名或加密的情況下創(chuàng)建。不安全的JWT是使用“alg”頭參數(shù)值“none”的JWS，并且具有JWA規(guī)范[JWA]中定義的JWS簽名值的空字符串; 它是一個不安全的JWS，JWT聲明集合作為其JWS有效載荷。
6.1 無擔(dān)保的JWT示例
以下示例JOSE Header聲明編碼對象是Unsecured JWT：
{"alg":"none"}
Base64url編碼JOSE頭的UTF-8表示的八位字節(jié)產(chǎn)生這個編碼的JOSE標(biāo)頭值：
eyJhbGciOiJub25lIn0
以下是JWT聲明集的示例：
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
Base64url編碼JWT聲明集合的UTF-8表示形式的八位字節(jié)產(chǎn)生此編碼的JWS有效載荷（僅用于顯示目的）
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
編碼的JWS簽名是空字符串。
按照這個順序?qū)⑦@些編碼部分連接在部件之間的周期（'.'）字符之間產(chǎn)生這個完整的JWT（僅用于顯示目的）
eyJhbGciOiJub25lIn0
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
7 創(chuàng)建和驗證JWT
7.1 創(chuàng)建JWT
要創(chuàng)建JWT，執(zhí)行以下步驟。 在步驟的輸入和輸出之間沒有依賴關(guān)系的情況下，步驟的順序不重要。
- 創(chuàng)建包含所需聲明的JWT聲明集。 注意，在表示中明確允許空格，并且在編碼之前不需要執(zhí)行規(guī)范化。
- 讓消息成為JWT聲明集的UTF-8表示的八位字節(jié)。
- 創(chuàng)建一個包含所需的頭參數(shù)集的JOSE頭。 JWT必須符合[JWS]或[JWE]規(guī)范。 注意，在表示中明確允許空格，并且在編碼之前不需要執(zhí)行規(guī)范化。
- 根據(jù)JWT是JWS還是JWE，有兩種情況：
- 如果JWT是JWS，則使用Message作為JWS有效負載創(chuàng)建JWS; 必須遵循用于創(chuàng)建JWS的[JWS]中指定的所有步驟。
- 否則，如果JWT是JWE，則使用Message作為JWE的明文創(chuàng)建一個JWE; 必須遵循[JWE]中為創(chuàng)建JWE而指定的所有步驟。
- 如果將執(zhí)行嵌套簽名或加密操作，請將消息作為JWS或JWE，并使用該步驟中創(chuàng)建的新JOSE頭中的“cty”（內(nèi)容類型）值“JWT”返回到步驟3。
- 否則，讓JWT成為JWS或JWE。
7.2 驗證JWT
驗證JWT時，執(zhí)行以下步驟。 在步驟的輸入和輸出之間沒有依賴關(guān)系的情況下，步驟的順序不重要。 如果任何列出的步驟失敗，則JWT必須被拒絕 - 也就是被應(yīng)用程序視為無效輸入。
驗證JWT是否包含至少一個句點（'.'）。
讓編碼的JOSE標(biāo)題在第一個（'.'）字符之前成為JWT的一部分。
Base64url解碼編碼的JOSE標(biāo)題，遵循不使用換行符，空格或其他附加字符的限制。
驗證結(jié)果八位字節(jié)序列是符合RFC 7159 RFC7159的完全有效的JSON對象的UTF-8編碼表示形式。 讓JOSE Header成為這個JSON對象。
驗證生成的JOSE頭只包含其語法和語義都被理解和支持的參數(shù)和值，或者在不明白的情況下被指定為被忽略。
使用JWE第9節(jié)中描述的任何方法確定JWT是JWS還是JWE。
-
根據(jù)JWT是JWS還是JWE，有兩種情況：
如果JOSE標(biāo)頭包含“cty”（內(nèi)容類型）值“JWT”，則該消息是作為嵌套簽名或加密操作主題的JWT。 在這種情況下，返回步驟1，使用Message作為JWT。
否則，base64url解碼消息，遵循沒有換行符，空格或其他附加字符的限制。
驗證結(jié)果八位字節(jié)序列是符合RFC 7159 [RFC7159]的完全有效的JSON對象的UTF-8編碼表示形式。 讓JWT聲明集成為這個JSON對象。
最后，請注意，在給定的上下文中可以使用哪種算法。 即使JWT可以成功驗證，除非JWT中使用的算法可以被應(yīng)用程序所接受，否則它應(yīng)該拒絕JWT。
7.3 字符串比較規(guī)則
處理JWT不可避免地需要將已知字符串與JSON對象中的成員和值進行比較。 例如，在檢查算法的情況下，將根據(jù)JOSE標(biāo)頭中的成員名稱檢查Unicode UNICODE字符串編碼“alg”，以查看是否存在匹配的標(biāo)題參數(shù)名稱。
RFC 7159第8.3節(jié)描述了進行成員名稱比較的JSON規(guī)則。 由于執(zhí)行的唯一的字符串比較操作是相等和不等式，因此可以使用相同的規(guī)則來比較成員名稱和成員值與已知字符串的比較。
這些比較規(guī)則必須用于所有的JSON字符串比較，除非成員的定義顯式地調(diào)用不同的比較規(guī)則用于該成員值。 在本規(guī)范中，只有“typ”和“cty”成員值不使用這些比較規(guī)則。
一些應(yīng)用程序可能包含區(qū)分大小寫的值中的不區(qū)分大小寫的信息，例如將DNS名稱作為“iss”（發(fā)行者）聲明值的一部分。 在這些情況下，應(yīng)用程序可能需要為規(guī)范情況定義一個約定，用于表示不區(qū)分大小寫的部分，例如，如果多個方可能需要生成相同的值才能進行比較，比如縮小它們。 （但是，如果所有其他方都消費生產(chǎn)者逐字排出的價值，而不嘗試將其與獨立產(chǎn)生的價值進行比較，則生產(chǎn)者使用的情況并不重要。）
8 實施要求
本節(jié)定義了本規(guī)范的哪些算法和功能是必須實現(xiàn)的。 使用此規(guī)范的應(yīng)用程序可以對其使用的實現(xiàn)施加額外的要求。 例如，一個應(yīng)用程序可能需要支持加密的JWT和嵌套JWT，而另一個應(yīng)用程序可能需要使用P-256曲線和SHA-256散列算法（“ES256”）來支持使用橢圓曲線數(shù)字簽名算法（ECDSA）簽名JWT。
在JSON Web算法JWA中指定的簽名和MAC算法中，只有HMAC SHA-256（“HS256”）和“none”必須通過符合JWT實現(xiàn)來實現(xiàn)。 推薦實現(xiàn)還使用SHA-256哈希算法（“RS256”）和使用P-256曲線和SHA-256哈希算法（“ES256”）的ECDSA支持RSASSA-PKCS1-v1_5。 支持其他算法和密鑰大小是可選的。
支持加密的JWT是可選的。 如果一個實現(xiàn)提供加密功能，在JWA中指定的加密算法中，只有具有2048位密鑰（“RSA1_5”）的RSAES-PKCS1-v1_5，具有128位和256位密鑰的AES密鑰包（“A128KW”和 “A256KW”），使用AES-CBC和HMAC SHA-2（“A128CBC-HS256”和“A256CBC-HS512”）的復(fù)合認證加密算法必須通過一致的實現(xiàn)來實現(xiàn)。 建議實現(xiàn)還支持使用橢圓曲線Diffie-Hellman臨時靜態(tài)（ECDH-ES）來同意用于包裝內(nèi)容加密密鑰（“ECDH-ES + A128KW”和“ECDH-ES + A256KW”）的密鑰，以及 具有128位和256位密鑰（“A128GCM”和“A256GCM”）的伽羅瓦/計數(shù)器模式（GCM）的AES。 支持其他算法和密鑰大小是可選的。
對嵌套JWT的支持是可選的。
9 聲明Content是JWT的URI
該規(guī)范注冊URN“urn：ietf：params：oauth：token-type：jwt”供應(yīng)用程序使用，該應(yīng)用程序使用URI聲明內(nèi)容類型（而不是例如媒體類型）來表示所引用的內(nèi)容是JWT。
10 IANA注意事項
10.1 JSON Web令牌聲明注冊表
本節(jié)為JWT聲明名稱建立IANA“JSON Web令牌聲明”注冊表。 注冊表記錄了聲明名稱和對定義它的規(guī)范的引用。 本節(jié)記錄第4.1節(jié)中定義的聲明名稱。
根據(jù)一個或多個指定專家的建議，在jwt-reg-review@ietf.org郵件列表上進行為期三周的審查期后，值將以規(guī)范要求RFC5226進行注冊。 然而，為了允許在出版之前分配價值，指定專家一旦確信這樣的規(guī)范將被公布，就可以批準(zhǔn)注冊。
發(fā)送到郵件列表進行審查的注冊請求應(yīng)使用適當(dāng)?shù)闹黝}（例如“請求注冊聲明：示例”）。
在審查期內(nèi)，指定專家將批準(zhǔn)或拒絕注冊請求，將此決定通知審查清單和IANA。 拒絕應(yīng)該包括解釋，如果適用的話，應(yīng)該提出如何使請求成功的建議。 長達21天以上未注冊的注冊請求可以通過IESG的注意（使用iesg@ietf.org郵件列表）進行解決。
指定專家應(yīng)適用的標(biāo)準(zhǔn)包括確定提議的注冊是否與現(xiàn)有功能重復(fù)，是否可能具有一般適用性，還是僅對單個應(yīng)用程序有用，以及注冊描述是否明確。
IANA只能接受指定專家的注冊表更新，并應(yīng)將所有注冊請求引導(dǎo)到審閱郵件列表。
建議指定多名指定專家，使用本規(guī)范能夠代表不同應(yīng)用的觀點，以便能夠?qū)ψ詻Q策進行廣泛的了解。
如果注冊決定可能被認為是為特定專家造成利益沖突的情況，該專家應(yīng)該依照其他專家的判斷。
