OpenID Attribute Exchange 1.0 - 最終版

Abstract

OpenID Attribute Exchange は、エンドポイント間で属性情報を交換するための OpenID の拡張仕様である。ユーザーの属性情報を更新または取得するためのメッセージを提供する。

Table of Contents

1.  要求記法および規則
    1.1.  用語
2.  Overview
3.  情報モデル
    3.1.  対象識別子
    3.2.  属性タイプ識別子
    3.3.  属性値
        3.3.1.  属性固有のエンコーディング
4.  ディスカバリー
5.  フェッチメッセージ
    5.1.  フェッチ要求形式
    5.2.  フェッチ応答形式
6.  ストアメッセージ
    6.1.  ストア要求形式
    6.2.  ストア応答形式
        6.2.1.  保存成功
        6.2.2.  保存失敗
7.  セキュリティ事項
8.  謝辞
9.  References
    9.1.  Normative References
    9.2.  Non-normative References
§  Authors' Addresses

1.  要求記法および規則

用いられる各キーワード「MUST (しなければならない) 」、「MUST NOT (してはならない) 」、「REQUIRED (必須である) 」、「SHALL (するものとする) 」、「SHALL NOT (しないものとする) 」、「SHOULD (すべきである) 」、「SHOULD NOT (すべきではない) 」、「RECOMMENDED (推奨される) 」、「MAY (してもよい) 」、「OPTIONAL (任意である) 」は [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) で述べられている通りに解釈されるべきものである。

1.1.  用語

ユーザー

エンドユーザー、または利用者のこと。Web ブラウザなどのクライアントソフトウェアを利用して、OpenID ベースで属性情報の交換を行うデジタルアイデンティティの所有者を指す。

アイデンティティ情報

"name" と "value" のペアで表現される、デジタルアイデンティティが持つ属性項目とその値。

属性

アイデンティティ情報を交換することを目的に、アイデンティティ情報自身を表すための情報モデルのベースとなるもの。

ペルソナ

ユーザーが持つアイデンティティ情報のサブセット。ユーザーは自身のアイデンティティの一部として、複数のペルソナを持つことができる。例えば、ビジネス用のペルソナとプライベート用のペルソナを持つことができる。

OpenID プロバイダ

"OP" または "Server" ともいう。エンドユーザが識別子を管理しているというアサーション (assertion) を得るために RP が依存する OpenID 認証サーバ。

リライングパーティ

"RP" または "Consumer" ともいう。エンドユーザが識別子を管理しているという証明を要求するウェブアプリケーション。

すべての OpenID Attribute Exchange のメッセージは、OpenID-Authentication-2.0 の拡張仕様の項目で定義されている名前空間の宣言を含む必要がある (MUST)。

openid.ns.<extension_alias>=http://openid.net/srv/ax/1.0

複数の拡張仕様のコンフリクトを避けるため、実際にリライングパーティがメッセージを構成する際にはメッセージひとつひとつに対して厳密に拡張名前空間を決めるべきである。このドキュメントでは、Attribute Exchange の拡張名前空間が "ax" となることを前提としている。

2.  Overview

Attribute Exchange サービスの拡張仕様は、"http://openid.net/srv/ax/1.0" の URI によって識別できる。この URI は名前空間宣言の拡張で規定されている必要がある (MUST)。

属性とは、一意の URI で識別される個人のユーザー情報の単位のことであり、あらゆる種類の情報を参照することがある。定義されている属性のタイプについては [OpenID.axschema] (Hardt, D., “Schema for OpenID Attribute Exchange,” May 2007.) を参照すること。

この拡張仕様では属性を送るために、fetch (Section 5 (フェッチメッセージ) を参照) と store (Section 6 (ストアメッセージ) を参照) の2つのメッセージタイプを定義している。Fetch は OP から属性情報を取得し、一方で store では OP 上の属性情報を更新する。これら2つのリライングパーティからのメッセージは、OpenID Authentication のプロトコルに従いユーザーエージェントを経由して OP へ送られる。

ここで詳述されているこれらのリクエストパラメータについては [OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0 - Final,” August 2007.) の拡張のしくみを使って送信されなくてはならない (MUST)。

3.  情報モデル

OpenID Attribute Exchange のサービス拡張仕様は、シンプルな情報モデルによりユーザー情報をサイト間で移動するためのしくみを提供する。

属性は対象の識別子に紐付く

属性は識別子のタイプと値を持つ

属性タイプの識別子はURIである

属性の値はどのような種類のデータも扱える

3.1.  対象識別子

属性のセットのための識別子。URI である必要がある (MUST)。対象識別子は、認証の最後のメッセージに含まれるエンドユーザー識別子に準じてる。言い換えると、Attribute Exchange でのユーザー属性の一部はエンドユーザーの認証の一部に相当するといえる。この対象識別子は Attribute Exchange には含まれない。

3.2.  属性タイプ識別子

属性タイプ識別子は URI である必要があり (MUST)、プロパティ値を参照する形で利用される。

属性タイプ識別子 URI は、それをプロパティの記述を参照するために取得することによって解決できるべきである。OP は新しいまたは未知の属性タイプのメタデータを取得して参照することで、ユーザーが属性を提供することを動的に支援することができる。

これにより柔軟性と拡張性が提供される。柔軟性という面では URN と URL の両方でプロパティ値を参照できる。拡張性という面では個人のサイトや企業のサイトでも、紐付く属性値の構文と意味付けを規定することで、所有する属性情報のタイプを明確にすることができる。

[OpenID.axschema] (Hardt, D., “Schema for OpenID Attribute Exchange,” May 2007.) にそれらの定義方法や新しい属性タイプ URI、また OP が属性タイプに紐付くメタデータのスキーマ、データ形式の概略を掲載しているので参照すること。

3.3.  属性値

属性値は UTF-8 (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.) [RFC3629] の文字列である必要がある (MUST)。データ形式については [OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0 - Final,” August 2007.) プロトコルで定義されている内容に従い、属性値は改行 (UCSコード10, "\n") を含んではならない (MUST NOT)。

OpenID Attribute Exchange はどんな種類のデータでも送信することができる。もしデータに改行を含んだり、UTF-8 文字列でない、または送信者がそう望む場合は、改行を含まない UTF-8 の文字列にエンコードしなければならない (MUST)。

3.3.1.  属性固有のエンコーディング

属性にメタデータを記述することにより属性固有のエンコーディング方法を定義することも可能で、OpenID Attribute Exchange のプロトコルレイヤーに適用させることもある。

オプションではあるが、ローカライズを行う場合は [OpenID.value‑lang‑1.0] (Wahl, M., “Language Tags for OpenID Values,” April 2007.) の language tags を利用して属性固有のエンコーディングを行うこともできる。

4.  ディスカバリー

Attribute Exchange サービス拡張のディスカバリーは、[OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0 - Final,” August 2007.) に記載されている方法により実現される。Attribute Exchange の名前空間 "http://openid.net/srv/ax/1.0" は、XRDS discovery ドキュメントのなかの <xrd:Type> の子要素である <xrd:Service> 要素でリストされるべきである (SHOULD)。

5.  フェッチメッセージ

フェッチメッセージは個人の属性情報を OP から取得するのに使用される。

5.1.  フェッチ要求形式

以下のリクエストフィールドのうち "openid.ax.mode" 以外はオプション (OPTIONAL) だが、"openid.ax.required" あるいは "opened.ax.if_available" のどちらかは必ずリクエストに含めなければならない (MUST)。また、"openid.ax.required" あるいは "openid.ax.if_available" のパラメータ内のどの属性エイリアスも紐付いた "openid.ax.type.<alias>" パラメータを保持しなければならない (MUST)。属性エイリアスの長さは少なくとも32文字までサポートされていなければならない (MUST)。

"openid.ax.required" あるいは "openid.ax.if_available" ディレクティブ内の複数の属性エイリアスはカンマ区切りで記述される。

openid.ax.mode

必須 (REQUIRED)。値: "fetch_request"

openid.ax.type.<alias>

このパラメータの値には送信された属性のタイプ識別 URI が指定される。<alias> は交換される属性を識別するのに再度使用される。

属性エイリアスは [OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0 - Final,” August 2007.) のデータフォーマット/プロトコルメッセージの項で指定されているように改行やコロンを含んではならなず (MUST NOT)、またカンマ (",") やピリオド (".") も含んではならない (MUST NOT)。

openid.ax.required

値: 属性エイリアス、もしくは "openid.ax.type.<alias>" パラメータで定義された URI と紐付いたエイリアスのリスト。複数の属性のエイリアスはコンマ (",") で区切られる。

このフィールドを使用して属性情報のリクエストを送信することで、RP は OP に特定の機能の提供を要求していることを伝えることができる。OP はユーザーがどの属性を公開するか決定する際に、その情報を用いて支援を行うべきである。RP の要求は OP によって強制されるべきではない。

Attribute Exchange で属性を取得できない場合、RP はユーザーに対して Attribute Exchange の範疇を超える話であるが、必要な属性を受け取る代替の手法を提示するべきである。

openid.ax.if_available

値: 属性エイリアス、もしくは "openid.ax.type.<alias>" パラメータで定義された URI と関連したエイリアスのリスト。複数の属性のエイリアスはコンマ (",") で区切られる。

このフィールドを使用して要求された属性は RP によってオプションとみなされたものである。オプションの属性を OP が提供していなかった場合でも、RP はユーザーとの対話を完了できるようにするべきである。

openid.ax.count.<alias>

RP が OP から受け取ることを希望している指定された属性エイリアス値の数。もし存在する場合は、値が0より大きい、もしくは OP が持ちうるかぎりの属性の値を RP が要求していることを表す特別な値 "unlimited" でなければならない (MUST)。もし存在しない場合は、厳密に1つの値が要求されているということである。

OP はこのフィールドで指定された属性の値の数の通りか、もしくはそれより少ない数を返してもよいが (MAY)、要求された属性の値の数より多く返してはならない (MUST NOT)。

openid.ax.update_url

この値がもし存在する場合、OpenID 認証のポジティブアサーションを使用して初回の応答が送信された後に、OP は指定された URL にフェッチ応答メッセージを再送信してもよい。OP がこの機能をサポートしているならば、フェッチ応答メッセージの一部としてパラメータを返さなければならない (MUST)。もしこの機能に対応していない場合は、このパラメータを無視してよい。

"openid.ax.update_url" フィールドの値は根底の仕様であるフェッチ応答の更新の OpenID 認証ポジティブアサーションの "openid.return_to" の値として使用されなければならない (MUST)。

もし "openid.realm" フィールドが存在する場合、"openid.ax.update_url" の値はベースの OpenID フェッチ要求メッセージで指定されている realm と照合しなければならない (MUST)。照合ルールは OpenID 認証プロトコルの "Realms" の項で定められているものと同じである。

この"要求していない"応答メッセージは属性情報更新のための応答の際に生成され、更新されたデータを含んでいるだろう。OpenID ポジティブアサーション送信時と同様に、OP は RP に更新されたデータを再送信するのにユーザーの同意を得るべきである。

リライングパーティーは属性情報と対象識別子を比較するために充分な情報を含む、エンコードされたトランザクションデータを URL に含んでも良い。必要に応じてリライングパーティーにより追加情報がエンコードされた URL に含まれる。

RP が属性の更新をこれ以上希望しない場合、update_url に紐付いた404の HTTP ステータスコードを返してもよい (MAY)。OP は404のステータスコードを受け取ったら更新情報を送信しないようにしてもよい (MAY)。

以下の例では、氏名と性別情報を必須、お気に入りの犬と映画の情報をオプションとして要求している。リライングパーティは項目識別子と関連づけられた3つのお気に入り映画を希望している。

openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ax.mode=fetch_request
openid.ax.type.fname=http://example.com/schema/fullname
openid.ax.type.gender=http://example.com/schema/gender
openid.ax.type.fav_dog=http://example.com/schema/favourite_dog
openid.ax.type.fav_movie=http://example.com/schema/favourite_movie
openid.ax.count.fav_movie=3
openid.ax.required=fname,gender
openid.ax.if_available=fav_dog,fav_movie
openid.ax.update_url=http://idconsumer.com/update?transaction_id=a6b5c41

5.2.  フェッチ応答形式

フェッチ応答メッセージはフェッチ要求された情報を提供する。左辺として各属性は割り当てられた "openid.ax.value." で始まるエイリアス、右辺としてその属性値が提供される。属性タイプもまた "openid.ax.type.<alias>" パラメータで返される。属性エイリアスの長さは少なくとも32文字までサポートされていなければならない (MUST)。

"openid.ax.mode" を除いて、以下の全ての要求フィールドはオプションである (OPTIONAL) が、"openid.ax.value.<alias>" パラメータ内に存在するいかなる属性値も "openid.ax.type.<alias>" パラメータと紐付けられていなければならない (MUST)。

ユーザーから値を提供されていないか利用できない場合、紐付けられた "openid.ax.value.<alias>" フィールドは OP のフェッチ応答に含まれるべきではない (SHOULD NOT)。"openid.ax.count.<alias>" の値が0で紐付けされた "openid.ax.type.<alias>" フィールドと同時に指定されている場合、何の属性値も提供されないことを明示している。

Attribute Exchange の仕様外であるが、受け取ったデータの検証は RP によって行われるべきである。

openid.ax.mode

必須 (REQUIRED)。値: "fetch_response"

openid.ax.type.<alias>

このパラメータの値にはフェッチ応答内の属性のタイプ識別 URI が指定される。<alias> は交換される属性を識別するのに再度使用される。

属性エイリアスは [OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0 - Final,” August 2007.) のデータフォーマット/プロトコルメッセージの項で規定されているように改行やコロンを含んではならない (MUST NOT) し、カンマ (",") やピリオド (".") も含んではならない (MUST NOT)。

openid.ax.count.<alias>

<alias> で参照される属性値の個数。

openid.ax.value.<alias>

<alias> として表された属性の値が割り当てられる。"openid.ax.count.<alias>" が送信されていない時は、このパラメータ形式を使用しなければならない (MUST)。

openid.ax.value.<alias>.<number>

<alias> として表された属性の値が割り当てられる。"openid.ax.count.<alias>" が送信され、少なくとも1つの値が該当する属性値として提供されている場合には、このパラメータ形式を使用しなければならない (MUST)。

<number> は1から "openid.ax.count.<alias>" で指定された値までの範囲のインデックスを一意的に識別する。パラメータ数は "openid.ax.count.<alias>" で指定された値と同一でなければならない (MUST)。OP はフェッチ応答の際に属性値の並び順を保つ必要はない。

openid.ax.update_url

リクエストで指定された "update_url" を返す。OP が "update_url" パラメータを受け取り、属性更新機能をサポートする意思がある場合、OP はフェッチ応答メッセージの一部に update_url パラメータと値を返さなければならない (MUST)。

フェッチ応答メッセージは、OP 上での属性値更新に応じて、Section 5.1 (フェッチ要求形式) で指定された "update_url" に送信されることもある。

前項で氏名を必須でお気に入りの犬情報をオプションとしたリクエスト例に対する応答を示す、3つの映画名が要求されたとしても、OP は2つの値しか提供していない。

openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ax.mode=fetch_response
openid.ax.type.fname=http://example.com/schema/fullname
openid.ax.type.gender=http://example.com/schema/gender
openid.ax.type.fav_dog=http://example.com/schema/favourite_dog
openid.ax.type.fav_movie=http://example.com/schema/favourite_movie
openid.ax.value.fname=John Smith
openid.ax.count.gender=0
openid.ax.value.fav_dog=Spot
openid.ax.count.fav_movie=2
openid.ax.value.fav_movie.1=Movie1
openid.ax.value.fav_movie.2=Movie2
openid.ax.update_url=http://idconsumer.com/update?transaction_id=a6b5c41

6.  ストアメッセージ

ストアメッセージはユーザー情報を OP に保存するために使用される。RP はこのメッセージを送信することで、自身が持つ属性値を OP に移譲することができる。送信された属性値は他の RP にも同様に送信することができ、ユーザーにとって役立つであろう。属性エイリアスは少なくとも32文字までサポートされていなければならない (MUST)。

ストア要求を受けた際に、属性をどのように更新をするかという OP 側のプロセスについては本ドキュメントのスコープ外とする。

6.1.  ストア要求形式

以下のリクエストフィールドのうち "openid.ax.mode" 以外はオプションである (OPTIONAL)。 "openid.ax.value.<alias>" または "openid.ax.value.<alias>.<number>" で示されるどのエイリアスも、"openid.ax.type" と紐付かなければならない (MUST)。

openid.ax.mode

必須 (REQUIRED)。値: "store_request"

openid.ax.type.<alias>

このパラメータの値にはストア要求内の属性のタイプ識別 URI が指定される。<alias> は後に交換される属性を識別するのに使用される。

属性エイリアスは [OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0 - Final,” August 2007.) のデータフォーマット/プロトコルメッセージの項で規定されているように改行やコロンを含んではならない (MUST NOT) し、カンマ (",") やピリオド (".") も含んではならない (MUST NOT)。

openid.ax.count.<alias>

<alias> で参照される属性値の個数。もし存在する場合は0より大きくなければならない (MUST)。

openid.ax.value.<alias>

<alias> として表された属性の値が割り当てられる。"openid.ax.count.<alias>" が送信されていない時は、このパラメータ形式を使用しなければならない (MUST)。

openid.ax.value.<alias>.<number>

<alias> として表された属性の値が割り当てられる。<number> は1から openid.ax.count<alias> で指定された値までの範囲の値のインデックスを一意的に識別する。"openid.ax.count.<alias>"　が送信された時は、このパラメータ形式を使用しなければならない (MUST)。これらのパラメータの数は、"openid.ax.count.<alias>" で指定された値と同じでなければならない (MUST)。

openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ax.mode=store_request
openid.ax.type.fname=http://example.com/schema/fullname
openid.ax.value.fname=Bob Smith
openid.ax.type.fav_movie=http://example.com/schema/favourite_movie
openid.ax.count.fav_movie=2
openid.ax.value.fav_movie.1=Movie1
openid.ax.value.fav_movie.2=Movie2

6.2.  ストア応答形式

6.2.1.  保存成功

正常なストア操作はストア応答内の mode パラメータによって示されている。

openid.ax.mode

必須 (REQUIRED)。値: "store_response_success"

openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ax.mode=store_response_success

6.2.2.  保存失敗

保存失敗の応答は以下のフォーマットのとおり。

openid.ax.mode

必須 (REQUIRED)。値: "store_response_failure"

openid.ax.error

オプション (OPTIONAL)。ユーザへの通知を想定した、失敗応答の原因となるエラー条件を表すパラメータ。メッセージのロケールは HTTP メッセージのロケールと一致するべきである。

openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ax.mode=store_response_failure
openid.ax.error=General storage failure

7.  セキュリティ事項

OpenID Attribute Exchange は OpenID の拡張であり、それゆえ属性の交換に OpenID 認証要求と応答メッセージを使用している。

[OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0 - Final,” August 2007.) の"セキュリティ事項"を参照すること。

8.  謝辞

John Merrells をはじめとした 'draft-merrells-dix' への寄稿者の方々に感謝する。ドキュメントの一部は本仕様のために利用された。

Mark Wahiに属性のエンコードに関する問題の対処方法のアドバイスをいただいた。

9.  References

9.1. Normative References

9.2. Non-normative References

Authors' Addresses