概述
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)標準跟蹤文檔暂氯。
本文檔是互聯(lián)網(wǎng)工程任務組（IETF）的產(chǎn)品潮模。它代表了IETF社區(qū)的共識。已獲得公眾意見審查痴施，并獲準由互聯(lián)網(wǎng)工程指導小組（IESG）出版擎厢。有關因特網(wǎng)標準的更多信息，請參考RFC 5741第二節(jié)
版權(quán)聲明
Copyright (c) 2015 IETF Trust和認證的文檔作者辣吃。版權(quán)所有动遭。
1 介紹
JSON Web令牌（JWT）是一種緊湊的聲明表示格式，適用于空間受限的環(huán)境神得，如HTTP授權(quán)標頭和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 公共標識
關鍵字"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 和"OPTIONAL"將被解釋為“用于指示要求級別的關鍵詞”RFC2119描述的那樣形入。只有當術(shù)語出現(xiàn)在所有大寫字母中時才應用該解釋。
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聲明集中的成員名稱稱為聲明名稱天梧。 相應的值稱為聲明值盔性。
JOSE標題的內(nèi)容描述了應用于JWT聲明集的加密操作。 如果JOSE標頭用于JWS呢岗，則JWT被表示為JWS冕香，聲明是數(shù)字簽名或MACed，JWT聲明集是JWS有效載荷后豫。 如果JOSE標頭用于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標頭在此示例中使用的實際UTF-8表示的八位字節(jié)序列也包含在下面茫打。 （請注意，由于換行符（CRLF對LF）的不同平臺表示，行的開始和結(jié)束處的不同間距老赤，最后一行是否具有終止換行符轮洋，以及其他原因，可能會導致模糊抬旺。 在這個例子中弊予，第一行沒有前導或者后面的空格，在第一行和第二行之間出現(xiàn)一個CRLF換行符（13,10）开财，第二行有一個前導空格（32）汉柒，沒有尾隨空格，最后一行 沒有終止換行符责鳍。）在此示例中使用JOSE標頭的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標頭值：
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標題的MAC和編碼的JWS有效載荷，并以[JWS]中指定的方式對HMAC值進行base64url生成此編碼的JWS簽名：
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
按照這個順序?qū)⑦@些編碼部分連接在部件之間的周期（'.'）字符之間產(chǎn)生這個完整的JWT（僅用于顯示目的）：
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
該計算在[JWS]的附錄A.1中有更詳細的說明历葛。 有關加密JWT的示例正塌，請參見附錄A.1。
4 JWT 聲明
JWT聲明集代表一個JSON對象恤溶，其成員是JWT傳達的聲明乓诽。 JWT聲明集中的聲明名稱必須是唯一的; JWT解析器必須拒絕具有重復的聲明名稱的JWT，或者使用JSON語法分析器咒程，該語法僅返回最后一個重復的成員名稱鸠天，如ECMAScript 5.1 ECMAScript的第15.12節(jié)（“JSON對象”）中所述。
JWT必須包含被認為有效的一組聲明是上下文相關的孵坚，超出了本規(guī)范的范圍粮宛。 JWT的具體應用將需要實現(xiàn)以特定方式理解和處理一些聲明。 然而卖宠，在沒有這樣的要求的情況下，實現(xiàn)中不了解的所有聲明必須被忽略忧饭。
有三類JWT索賠名稱：注冊索賠名稱扛伍，公開聲明名稱和私人聲明名稱。
4.1 注冊請求名稱
以下聲明名稱已注冊在由10.1節(jié)建立的IANA“JSON Web令牌聲明”注冊表中词裤。 以下定義的所有權(quán)利要求都不意味著在所有情況下使用或?qū)嵤┦菑娭菩缘拇倘鳎菫橐唤M有用的，可互操作的索賠提供了起點吼砂。 使用JWT的應用程序應該定義使用哪些特定聲明逆航，何時需要或可選。 所有的名稱都很短渔肩，因為JWT的核心目標是使其表現(xiàn)得很緊湊因俐。
4.1.1 "iss" (Issuer) 聲明
"iss" (issuer) 請求確定發(fā)出JWT的委托人。 這種說法的處理通常是具體的應用。 “iss”值是一個包含StringOrURI值的區(qū)分大小寫的字符串抹剩。 使用此聲明是可選的撑帖。
4.1.2 " sub" (Subject) 聲明
"sub" (Subject)請求確定作為JWT主題的委托人。JWT中的請求通常是關于該主題的陳述澳眷。 主體值必須在發(fā)行者的上下文中被限定為本地唯一的胡嘿，或者是全局唯一的。 這種說法的處理通常是具體的應用钳踊。 “sub”值是一個包含StringOrURI值的區(qū)分大小寫的字符串衷敌。 使用此聲明是可選的。
4.1.3 "aud" (Audience) 聲明
"aud" (audience)聲明識別JWT所針對的收件人拓瞪。旨在處理JWT的每個主體都必須在受眾聲明中確定自己的價值逢享。 如果索賠的主要處理在本聲明存在的情況下并未標明“aud”索賠中的值，那么JWT必須被拒絕吴藻。 在一般情況下瞒爬，“aud”值是一個區(qū)分大小寫的字符串數(shù)組，每個字符串都包含一個StringOrURI值沟堡。 在JWT有一個觀眾的特殊情況下侧但，“aud”值可以是包含StringOrURI值的單個區(qū)分大小寫的字符串。 觀眾價值觀的解釋一般是具體的應用航罗。 使用此聲明是可選的禀横。
4.1.4 "exp" (Expiration Time)請求
"exp" (expiration time)標識JWT不得接受處理之前或之后的到期時間。處理"exp"請求要求當前日期/時間必須在“exp”索賠中列出的到期日期/時間之前粥血。實施者可能會提供一些小的余地柏锄，通常不超過幾分鐘來解決時鐘偏差。 其值必須是包含NumericDate值的數(shù)字复亏。 使用此聲明是可選的趾娃。
4.1.5 "nbf" (Not Before) 請求
"nbf" (not before)請求標識JWT不得接受處理的時間。處理“nbf”請求要求當前日期/時間必須在“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提供唯一的標識符上祈。必須以確保相同值被意外分配給不同數(shù)據(jù)對象的可能性很小的方式來分配標識符值培遵；如果應用程序使用多個發(fā)行者浙芙，則必須在不同發(fā)行者產(chǎn)生的值之間防止沖突』缍“jti”請求可用于防止JWT重播茁裙。“jti”值是區(qū)分大小寫的字符串节仿。 使用此聲明是可選的晤锥。
4.2 公開聲明名稱
4.3 私有聲明名稱
5 JOSE頭
5.1 "typ"(Type)頭參數(shù)
5.2 "cty"(Content Type)頭參數(shù)
5.3 復制請求作為頭參數(shù)
6 無擔保的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 無擔保的JWT示例
以下示例JOSE Header聲明編碼對象是Unsecured JWT：
{"alg":"none"}
Base64url編碼JOSE頭的UTF-8表示的八位字節(jié)產(chǎn)生這個編碼的JOSE標頭值：
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í)行以下步驟傅寡。 在步驟的輸入和輸出之間沒有依賴關系的情況下放妈，步驟的順序不重要。
- 創(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í)行以下步驟丙挽。 在步驟的輸入和輸出之間沒有依賴關系的情況下，步驟的順序不重要匀借。 如果任何列出的步驟失敗颜阐，則JWT必須被拒絕 - 也就是被應用程序視為無效輸入。
驗證JWT是否包含至少一個句點（'.'）吓肋。
讓編碼的JOSE標題在第一個（'.'）字符之前成為JWT的一部分凳怨。
Base64url解碼編碼的JOSE標題，遵循不使用換行符是鬼，空格或其他附加字符的限制肤舞。
驗證結(jié)果八位字節(jié)序列是符合RFC 7159 RFC7159的完全有效的JSON對象的UTF-8編碼表示形式。 讓JOSE Header成為這個JSON對象均蜜。
驗證生成的JOSE頭只包含其語法和語義都被理解和支持的參數(shù)和值李剖，或者在不明白的情況下被指定為被忽略。
使用JWE第9節(jié)中描述的任何方法確定JWT是JWS還是JWE囤耳。
-
根據(jù)JWT是JWS還是JWE篙顺，有兩種情況：
如果JOSE標頭包含“cty”（內(nèi)容類型）值“JWT”铃剔，則該消息是作為嵌套簽名或加密操作主題的JWT撒桨。 在這種情況下，返回步驟1键兜，使用Message作為JWT凤类。
否則，base64url解碼消息普气，遵循沒有換行符谜疤，空格或其他附加字符的限制。
驗證結(jié)果八位字節(jié)序列是符合RFC 7159 [RFC7159]的完全有效的JSON對象的UTF-8編碼表示形式现诀。 讓JWT聲明集成為這個JSON對象夷磕。
最后，請注意仔沿，在給定的上下文中可以使用哪種算法坐桩。 即使JWT可以成功驗證，除非JWT中使用的算法可以被應用程序所接受封锉，否則它應該拒絕JWT绵跷。
7.3 字符串比較規(guī)則
處理JWT不可避免地需要將已知字符串與JSON對象中的成員和值進行比較膘螟。 例如，在檢查算法的情況下碾局，將根據(jù)JOSE標頭中的成員名稱檢查Unicode UNICODE字符串編碼“alg”荆残，以查看是否存在匹配的標題參數(shù)名稱。
RFC 7159第8.3節(jié)描述了進行成員名稱比較的JSON規(guī)則净当。 由于執(zhí)行的唯一的字符串比較操作是相等和不等式内斯，因此可以使用相同的規(guī)則來比較成員名稱和成員值與已知字符串的比較。
這些比較規(guī)則必須用于所有的JSON字符串比較蚯瞧，除非成員的定義顯式地調(diào)用不同的比較規(guī)則用于該成員值嘿期。 在本規(guī)范中，只有“typ”和“cty”成員值不使用這些比較規(guī)則埋合。
一些應用程序可能包含區(qū)分大小寫的值中的不區(qū)分大小寫的信息备徐，例如將DNS名稱作為“iss”（發(fā)行者）聲明值的一部分。 在這些情況下甚颂，應用程序可能需要為規(guī)范情況定義一個約定蜜猾，用于表示不區(qū)分大小寫的部分，例如振诬，如果多個方可能需要生成相同的值才能進行比較蹭睡，比如縮小它們。 （但是赶么，如果所有其他方都消費生產(chǎn)者逐字排出的價值肩豁，而不嘗試將其與獨立產(chǎn)生的價值進行比較，則生產(chǎn)者使用的情況并不重要辫呻。）
8 實施要求
本節(jié)定義了本規(guī)范的哪些算法和功能是必須實現(xiàn)的清钥。 使用此規(guī)范的應用程序可以對其使用的實現(xiàn)施加額外的要求。 例如放闺，一個應用程序可能需要支持加密的JWT和嵌套JWT祟昭，而另一個應用程序可能需要使用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”）的復合認證加密算法必須通過一致的實現(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”供應用程序使用，該應用程序使用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ī)范將被公布暖夭，就可以批準注冊锹杈。
發(fā)送到郵件列表進行審查的注冊請求應使用適當?shù)闹黝}（例如“請求注冊聲明：示例”）。
在審查期內(nèi)迈着，指定專家將批準或拒絕注冊請求竭望，將此決定通知審查清單和IANA。 拒絕應該包括解釋裕菠，如果適用的話咬清，應該提出如何使請求成功的建議。 長達21天以上未注冊的注冊請求可以通過IESG的注意（使用iesg@ietf.org郵件列表）進行解決奴潘。
指定專家應適用的標準包括確定提議的注冊是否與現(xiàn)有功能重復旧烧，是否可能具有一般適用性，還是僅對單個應用程序有用，以及注冊描述是否明確。
IANA只能接受指定專家的注冊表更新腮郊，并應將所有注冊請求引導到審閱郵件列表焕蹄。
建議指定多名指定專家，使用本規(guī)范能夠代表不同應用的觀點列林，以便能夠?qū)ψ詻Q策進行廣泛的了解。
如果注冊決定可能被認為是為特定專家造成利益沖突的情況，該專家應該依照其他專家的判斷予权。
