2024年10月27日日曜日

IETFに向けて色々とスペック案が。まずはToken Status Listから。

こんにちは、富士榮です。

SIDI Hub東京サミットが終わったと思ったら、来週からはInternet Identity Workshop、その翌週はIETFですね。(そしてその間にもOpenID Foundation Workshopがあったりします)


IETFに向けてOAuth WGから色々と仕様ドラフトが出ていますので、少しずつ紹介しようかと思います。

まずはToken Status Listです。

https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/


Verifiable Credentialsに関するStatus ListといえばDIFからW3Cに場を移したBitstring Status List v1.0がありますが、今回のものをざっとみているとJWT以外にmdocやCWTにも適用できるように汎用化した感じでしょうか。

クレデンシャルフォーマットがバラついている状況では必要なものなんだと思います。


Introductionにはこんなことが書いてあります。

Token formats secured by JOSE [IANA.JOSE] or COSE [RFC9052], such as JSON Web Tokens (JWTs) [RFC7519], CBOR Web Tokens (CWTs) [RFC8392] and ISO mdoc [ISO.mdoc], have vast possible applications. Some of these applications can involve issuing a token whereby certain semantics about the token can change over time, which are important to be able to communicate to relying parties in an interoperable manner, such as whether the token is considered invalidated or suspended by its issuer.

This document defines a Status List and its representations in JSON and CBOR formats that describe the individual statuses of multiple Referenced Tokens, which themselves are JWTs or CWTs. The statuses of all Referenced Tokens are conveyed via a bit array in the Status List. Each Referenced Token is allocated an index during issuance that represents its position within this bit array. The value of the bit(s) at this index correspond to the Referenced Token's status. A Status List may either be provided via HTTPS or be protected within a Status List Token by cryptographic signature or MAC, whereas this document defines its representations in JWT and CWT. Status Lists may be composed for expressing a range of Status Types. This document defines basic Status Types for the most common use cases as well as an extensibility mechanism for custom Status Types. The document also defines how an issuer of a Referenced Token references a Status List (Token).

JOSE [IANA.JOSE] または COSE [RFC9052] によって保護されたトークン形式、例えば、JSON Web トークン (JWT) [RFC7519]、CBOR Web トークン (CWT) [RFC8392]、ISO mdoc [ISO.mdoc] などには、幅広い用途が考えられます。これらのアプリケーションの一部では、トークンを発行し、そのトークンに関する特定の意味論が時間とともに変化する場合がある。これは、相互運用可能な方法で依拠当事者に通知することが重要であり、例えば、トークンが発行者によって無効または一時停止されたと見なされるかどうかなどである。

本書では、複数の参照トークン(それ自体はJWTまたはCWT)の個々のステータスを記述するステータスリストとその表現を、JSONおよびCBOR形式で定義します。すべての参照トークンのステータスは、ステータスリスト内のビット配列で伝達されます。各参照トークンには、発行時にこのビット配列内の位置を示すインデックスが割り当てられます。このインデックスのビットの値は、参照トークンのステータスに対応します。ステータスリストは、HTTPS経由で提供されるか、暗号署名またはMACによりステータスリストトークン内で保護される場合があります。一方、本書ではJWTおよびCWTにおける表現を定義しています。ステータスリストは、ステータスタイプの範囲を表現するために構成される場合があります。本書では、最も一般的なユースケースに対応する基本的なステータスタイプ、およびカスタムステータスタイプの拡張メカニズムを定義しています。また、参照トークンの発行者がステータスリスト(トークン)を参照する方法についても定義しています。


ちゃんとIHVモデルにも適用するモデルになっていますね。

issue present Referenced Referenced ┌────────┐ Token ┌────────┐ Token ┌───────────────┐ │ Issuer ├───────────►│ Holder ├───────────►│ Relying Party │ └─┬──────┘ └────────┘ └──┬────────────┘ ▼ update status │ ┌───────────────┐ │ │ Status Issuer │ │ └─┬─────────────┘ │ ▼ provide Status List │ ┌─────────────────┐ fetch Status List │ │ Status Provider │◄───────────────────────────┘ └─────────────────┘


サンプルも一緒に提示されています(こちらはJWTのケース)

{ "alg": "ES256", "kid": "12", "typ": "statuslist+jwt" } . { "exp": 2291720170, "iat": 1686920170, "status_list": { "bits": 1, "lst": "eNrbuRgAAhcBXQ" }, "sub": "https://example.com/statuslists/1", "ttl": 43200 }


まぁ、相変わらず微妙だなぁと思うのは結局Bitstringでステータスを表現している点(他のアイデアがあるかと言われるとありませんが)なわけですが、他にもStatus Providerをどうやって安全かつプライバシーに配慮した上で運営できるか?ってところになってきそうです。


いずれにしても非常に重要な仕様の一つだと思うので要ウォッチですね。


0 件のコメント:

コメントを投稿