OpenID Connectの『name』『given_name』クレームがCWTにやってくる──SPICE WGのOIDC-CWTを読む

ユーザーの氏名や名（given name）といった、OpenID Connectで標準化されている項目（クレーム）は、JWT（JSON Web Token）の世界ではすでに広く使われている。だが、IoTや省リソース環境向けのバイナリトークン形式であるCBOR Web Token（CWT）には、これらのクレームがまだ登録されていない。IETF SPICE（Secure Patterns for Internet CrEdentials）ワーキンググループのドラフト「OpenID Connect Standard Claims Registration for CBOR Web Tokens」（rev06、2026年7月23日更新、著者B. Maldant氏・M. B. Jones氏）の本文を確認すると、この空白を埋めるための、地味だが実務的な「対応表」を作る作業であることが分かる。

3行まとめ

• このドラフトは、OpenID ConnectがJWT向けに標準化したname・given_nameといったクレームを、CWTの「CBOR Web Token (CWT) Claims」IANAレジストリに登録するための、フィールドごとの対応表を定義する。クレーム名・説明・対応するJWTクレーム名・整数キー（Claim Key）・値の型・変更管理者を、クレームごとに列挙する形式
• sub（主体）クレームはOpenID Connectの標準クレーム一覧に含まれるが、既にCWTのレジストリに登録済みのため、このドラフトの対象からは意図的に除外されている
• 同じ日に公開する姉妹記事で扱うSD-CWT（選択的開示CBOR Web Token）のRustプロトタイプ実装（beltram/esdicawt）の作者B. Maldant氏（SimpleLogin社）が、このドラフトの筆頭著者でもある

なぜ必要か

ドラフトの導入部はこう説明している。

OpenID Connect [OpenID.Core] is an authentication standard including standard claims already in use for JSON Web Tokens (JWT) [RFC7519]. CBOR Web Tokens (CWT) [RFC8392] have a claims registry, but do not include most of these claims. This draft aims at unifying use of OpenID Connect claims in JWTs and CWTs.

（OpenID Connectは、JSON Web Token（JWT）で既に使われている標準クレームを含む認証標準だ。CBOR Web Token（CWT）はクレームのレジストリを持っているが、これらのクレームのほとんどを含んでいない。このドラフトは、JWTとCWTの両方でOpenID Connectのクレームの使い方を統一することを目指す）

クレームごとの対応表——名前・説明・整数キー

具体的な登録内容はこうだ。

3.1. name: Claim Name: name. Claim Description: End-User's full name in displayable form including all name parts, possibly including titles and suffixes, ordered according to the End-User's locale and preferences. JWT Claim Name: name. Claim Key: TBD1 (170 suggested). Claim Value Type(s): text string. Change Controller: IETF.

（3.1 name：クレーム名：name。クレームの説明：表示可能な形式のエンドユーザーのフルネーム。敬称や接尾辞を含む可能性のある全ての名前の部分を、エンドユーザーのロケールと好みに従った順序で含む。JWTクレーム名：name。クレームキー：TBD1（170が提案されている）。クレーム値の型：テキスト文字列。変更管理者：IETF）

CWTはJSONの文字列キーではなく整数キーを使うバイナリ形式のため、このように各クレームに新しい整数値（この例では170が提案）を割り当てる作業が必要になる。この対応表はname・given_nameをはじめとする複数のOpenID Connect標準クレームについて、同じ形式で繰り返されている。

subクレームは意図的に対象外

このドラフトの範囲設定にも注意書きがある。

Note that while the "sub" claim is included in the table of claims in Section 5.1 of [OpenID.Core], it is not included here because it is already registered in the "CBOR Web Token (CWT) Claims" [IANA.CWT.Claims] registry.

（subクレームはOpenID Connectのクレーム表（Section 5.1）に含まれているが、既に「CBOR Web Token (CWT) Claims」IANAレジストリに登録済みのため、ここには含まれていないことに注意してほしい）

これは、CWT自体が元々JWTのクレームセット（RFC 7519）を土台にした形式であり、subのような基本的なクレームはCWT標準化の初期段階（RFC 8392）で既に整備されていたためだ。このドラフトが埋めているのは、OpenID Connectが後から追加した、より詳細なユーザープロファイル系のクレームという、その先の部分になる。

全19クレームの対応表

ドラフト本文（Section 3.1〜3.19）を1つずつ確認し、提案キー番号と値の型を並べると次のようになる。

提案キーは170から188まで19個連番で並んでおり、addressだけがmap型（郵便番号や国名などを持つ入れ子構造）、email_verified・phone_number_verifiedが真偽値、updated_atが数値型で、残りはすべてtext stringになっている。

IANAレジストリを直接確認すると、170〜188番はまだ空いていた

「TBD1（170が提案）」という表記が示す通り、これらのキー番号はまだ正式に確定していない。実際にIANAの「CBOR Web Token (CWT) Claims」レジストリを直接開いて確認したところ、この記事の確認時点（2026年8月31日）で登録されているクレームキーのうち、最大の番号は169（MOSIPが登録したidentity-data）で、このドラフトが提案する170〜188番は、19番すべてがまだ登録されていない空き番号だった。ドラフトが「提案（suggested）」という表現を使っているのは伊達ではなく、このドラフトがAccepted相当の段階まで進んで正式にIANAへ登録されるまでは、他のドラフトが同じ番号帯を先に押さえる可能性もゼロではない。

クレーム全リストと採用実装までは確認していない

実際にどの実装がこのクレーム対応表を採用しているかについては、この記事の一次ソースの範囲では確認できなかった。著者B. Maldant氏によるSD-CWTのRust実装beltram/esdicawtはGitHub API実測でスター3（2026年8月31日確認）と、まだ小規模な個人プロジェクトの段階であることも確認した。この記事を書いている自分自身は、CWTやCOSEを使った認証システムの実装経験がなく、この対応表が実務上どれだけ急を要するものかについての判断材料は持たない。日本語ではZenn・Qiitaともに、このドラフト単体を扱った記事は検索時点で見当たらなかった。

関連記事: MCP（Model Context Protocol）とは

感想・指摘はコメント欄へ。