情報カード

情報カード(またはi-card ) は、人々がオンラインで使用できる個人のデジタル ID であり、ID メタシステムの重要なコンポーネントです。視覚的には、各 i-card にはカード型の画像とそれに関連付けられたカード名があり、人々はこれを使用してデジタル ID を整理し、特定のやり取りで使用する ID を簡単に選択できます。情報カードのメタファーは、Windows CardSpace、 DigitalMe 、Higgins Identity Selectorなどの ID セレクターによって実装されています。

アイデンティティ メタシステムは、複数の基盤技術、実装、プロバイダーに基づくデジタル アイデンティティのコレクションをユーザーが所有および使用できるようにする、デジタル アイデンティティの相互運用可能なアーキテクチャです。このアプローチを使用すると、顧客は既存のアイデンティティ インフラストラクチャへの投資を引き続き使用し、最適なアイデンティティ テクノロジを選択し、他のテクノロジとの相互運用性を犠牲にすることなく、古いテクノロジから新しいテクノロジに簡単に移行できます。アイデンティティ メタシステムは、「アイデンティティの法則」の原則に基づいています。^[1]

情報カードを使用したデジタル ID のやり取りには、次の 3 つの参加者がいます。 ^{[引用が必要]}

• アイデンティティ プロバイダーは、デジタル アイデンティティを発行します。たとえば、企業が顧客にアイデンティティを発行したり、政府が国民のアイデンティティを保証したり、クレジットカード発行会社が支払いを可能にするアイデンティティを提供したり、オンライン サービスが年齢などの検証済みデータを提供したり、個人が自分で発行したアイデンティティを使用して Web サイトにログオンしたりする場合があります。
• 証明書利用者(RP) は、ユーザーに代わって ID を受け入れます。ユーザーが使用するオンライン サービスは、ユーザーが選択したデジタル ID を受け入れ、ユーザーの同意を得て、ユーザーに代わって提供された情報を使用します。
• 主体とは、これらすべてのやり取りを制御する当事者であるあなた自身のことです。主体は、該当するデジタル ID のうち、どのデジタル ID を依存当事者に使用するかを選択できます。

アイデンティティセレクターは、デジタルアイデンティティを保存、管理、使用するために使用されます。アイデンティティセレクターの例としては、MicrosoftのWindows CardSpace、Bandit ProjectのDigitalMe、^{[2] 、} Eclipse FoundationのHigginsプロジェクトのいくつかの種類のアイデンティティセレクターなどがあります。

ID セレクターは、次のユーザー中心の ID 管理タスクを実行します。

• RP (サービス プロバイダーとも呼ばれる)との認証 (および場合によっては他の種類のやり取り) に対して一貫したユーザー エクスペリエンスを提供します。
• ローカル アプリケーションまたは依存パーティ (Web サイトのログイン ページなど) によって認証が必要な場合に、ユーザーが好みの i-card を選択できる一連の情報カード アイコンを表示するユーザー インターフェイスを提供します。
• 個人情報 (自己発行とも呼ばれる) カードを作成および管理するためのユーザー インターフェイスを提供します。
• 個人用 i カードのセキュリティ トークンを発行するために使用されるローカル セキュリティ トークン サービスを提供します。
• 標準ファイル形式で情報カードをインポートおよびエクスポートするためのユーザー インターフェイスを提供します。
• ブラウザ拡張機能またはローカルのリッチ クライアント アプリケーションによって呼び出されます。

アイデンティティ セレクターを使用すると、ユーザーは i-card ポートフォリオを管理 (たとえば、カードの作成、確認、更新、削除) することもできます。

アイデンティティ メタシステムには 5 つの主要コンポーネントがあります。

• クレームを使用して ID を表す方法。クレームは、WS-Securityに従ってセキュリティ トークンで伝達されます。
• アイデンティティ プロバイダー、依存当事者、およびサブジェクトがネゴシエートするための手段。配信されるクレームと使用されるセキュリティ トークン形式を動的にネゴシエートすることで、アイデンティティ メタシステムは、デジタル アイデンティティのやり取りに必要なあらゆる形式のトークンとあらゆる種類のクレームを運ぶことができます。ネゴシエーションは、WS-MetadataExchangeを使用して交換されるWS-SecurityPolicyステートメントを使用して行われます。
• クレームと要件を取得するためのカプセル化プロトコル。WS -TrustプロトコルとWS-Federationプロトコルは、セキュリティ トークンの要求とそれらのトークンを含む応答を送信するために使用されます。
• クレーム変換を使用して、テクノロジーと組織の境界を橋渡しする手段。WS -Trust で定義されているセキュリティ トークン サービス(STS) は、クレームの内容と形式を変換するために使用されます。
• 複数のコンテキスト、テクノロジ、オペレータにわたって一貫したユーザー エクスペリエンス。これは、ユーザーが所有するデジタル ID を視覚的な i カードとして表す Windows CardSpace などの ID セレクター クライアント ソフトウェアによって実現されます。

• I カードは、発行者と呼ばれる組織によって作成されます。
• I カードには、発行者の名前 ( issuerName ) がテキスト文字列で表示されます。
• I カードには、カード発行会社によって最初に設定されるカードを識別するためのテキスト文字列 ( cardName ) があります。通常、このカード名はユーザーが編集可能です。
• I カードには、カード発行者が設定した( GIFまたはJPEG ) 背景画像 ( cardImage ) が含まれる場合があります (ユーザーが編集可能)。
• ほとんどの i-card では、ユーザーは請求額を確認できます。

i-card を使用すると、ユーザーはすべての Web サイトでユーザー名とパスワードを必要とせずに認証できます。代わりに、i-card を受け入れているサイトでは、複数のサイトで使用できる i-card を使用してログインできます。

各情報カードは、キーが要求されるすべてのレルムに対して、異なるペアワイズ デジタル キーを使用します。レルムは、情報カードを要求するときに、すべて同じターゲット スコープ情報を共有する単一のサイトまたは関連サイトのセットです。レルムごとに異なるペアワイズ キーを使用するということは、i-card を使用して偽のサイトにログインするように誘導された場合でも、そのサイトでは、偽装者がなりすまそうとしたサイトとは異なるキーが使用されるため、共有シークレットは公開されません。

さらに、多くの ID セレクターはフィッシング検出の手段を提供しており、証明書利用者サイトのHTTPS証明書がチェックされ、ユーザーが以前に情報カードを使用したサイトのリストと比較されます。新しいサイトにアクセスすると、ユーザーはそこで以前にカードを使用していないことが通知されます。

アイデンティティセレクタ相互運用性プロファイルv1.5 ^[3]（またはOASIS IMI v1.0委員会草案）^[4]では、アイデンティティセレクタがサポートしなければならない2種類の情報カードが指定されています。

• 個人情報カード: (自己発行とも呼ばれます) これらのカードを使用すると、受け入れ可能なサイトに対して自分自身に関するクレームを発行できます。これらのクレームには、名前、住所、電話番号、電子メール アドレス、Web アドレス、生年月日、性別、およびカードが使用されるサイトごとに一意に生成されるサイト固有のキーを含めることができます。
• 管理情報カード: これらのカードを使用すると、自分以外の ID プロバイダーが、そのカードを受け入れるサイトに対して自分に関するクレームを行うことができます。これらのクレームには、RP が要求する情報、ID プロバイダーが提供できる情報、および RP 間で送信する意思のある情報を含めることができます。

Higginsプロジェクトでは、次の 2 種類の新しい i-card も定義しています。

• 関係カード (または R カード) は、複数の当事者間の継続的な関係を確立するために使用されます。
• ゼロ知識カード（Zカード）

ただし、情報カードの形式ではカスタム タイプが許可されます。Bandit プロジェクトは、 2007 年 3 月のNovell BrainShareカンファレンスで、OpenIDでサポートされるプロトタイプの管理カードのデモを行いました。

最初の種類の個人情報カードも、2006 年 11 月に Microsoft の Windows CardSpace ソフトウェアの一部として導入されました。その動作も、Microsoft 定義の管理カード (上記参照) を扱っている同じドキュメントで定義されています。

特徴の概要:

• データ形式は、クレーム タイプURIのセットとこれらのクレームの (ユーザー定義の) 値、cardImage 、一意の cardID などを含む XML ファイルです。このデータ形式は、ISIP ドキュメントで定義されています。
• 発行者:ユーザー自身のアイデンティティセレクタ。個人カードは自己発行カードとも言える。
• Genesis:ユーザーの ID セレクターによって作成されます。
• クレーム: 15個の定義済みクレームタイプ（例：名、姓、電子メールアドレスなど）が、Identity Selector Interoperability Profile v 1.5 ^[3]（またはOASIS IMI v1.0委員会草案）で定義されています。^[4]
• 権限:ユーザーの ID セレクターは、発行されたトークンのクレーム値セットの権限です。
• データ フロー:要求に応じて (たとえば、依存サイトで必要な場合)、ID セレクターのローカルSTSが現在の値を使用してセキュリティ トークンを作成します。
• 編集可能性:クレーム値はユーザーが直接編集できます。
• 属性データ ソース:個人カードの XML ファイルにはクレーム値が含まれています。これらのデータ値は、ID セレクターにインポートされると、セレクターによって内部的に管理されます。

最初の種類のマネージド カードは、2006 年 11 月に Microsoft の Windows CardSpace ソフトウェアの一部として導入されました。これらの種類のマネージド カードの動作、ファイル形式、相互運用性の特性については、Identity Selector Interoperability Profile v 1.5 ^[3] (または OASIS IMI v1.0 Committee Draft ^{[4] 、より完全なリストについては self-issued.info [5]}を参照) などの Microsoft ドキュメントと、WS-Trust ^[6]などのオープン スタンダードとの組み合わせによって定義されています。

特徴の概要:

• データ形式: STS のネットワーク エンドポイント、クレーム タイプ URI のセット、カード名、cardImage、issuerName、一意の cardID などを含む XML ファイル。XML ファイル形式は、ISIP ドキュメントで定義されています。
• 発行者:外部のサードパーティ トークン サービス (外部の個人または組織を表す)。
• Genesis:管理対象カードは、ID プロバイダー サイトで実行されているセキュリティ トークン サービスによって生成され、ユーザーの ID セレクターにインポートされます。
• クレーム:サポートされるクレーム タイプ (クレーム タイプ URI) のリストは、発行者によって定義されます。
• 権限:発行者は、発行するトークン内に含まれるクレーム値に対する唯一の権限を持ちます。
• データ フロー:マネージド カードには、 STSへのネットワーク エンドポイント参照が含まれており、ID セレクター (WS-Trust などを使用) によって要求されると、必要なクレームを含むセキュリティ トークンを生成/提供します。
• 編集可能性:基礎となる属性データはユーザーが直接編集することはできません。
• 属性データ ソース:発行者によって決定され、通常は発行者によって管理されます。

第三者が発行する I カードでは、ユーザーがカード所有者であることを認証するために次の 4 つの方法のいずれかを使用できます。

• 個人情報カード（自己発行）
• X.509証明書（スマートカードなどのハードウェア デバイスから取得することも、ソフトウェア証明書から取得することもできます）
• 多くのエンタープライズログインソリューションで発行されるKerberosチケット、または
• カードのユーザー名とパスワード。

将来の ID セレクターと ID プロバイダーによって追加のメソッドが実装される可能性もあります。

管理される i-card は、監査対象、非監査対象、または監査オプションのいずれかになります。

• 監査カードでは、 RPサイトの ID をID プロバイダーに開示する必要があります。これを使用して、ID プロバイダーが情報を公開するサイトを制限できます。
• 非監査カードでは、RP サイトの ID が ID プロバイダーに開示されません。
• 監査オプションのカードは、RP によって提供された場合、依存当事者サイトの ID を公開しますが、この公開は必須ではありません。

関係カードはヒギンズプロジェクトによって開発中です（ポール・トレビシックのレポートを参照）。^[7]

特徴の概要:

• データ形式:リソース udi クレームをサポートする管理カード。
• サポートされているクレーム:すべての管理対象 (または個人用) カードと同様に、r カードには発行者によって定義されたサポートされているクレーム タイプ (URI として表現) のリストが含まれます。このセットは、発行者が生成したセキュリティ トークンに含めるクレームの最大セットを定義します。これらのクレームは、そのベースとなる基礎となる ISIP-m カードから継承され、同じ目的で使用されます。管理対象カード以外では、resource-udi "meta" クレームが属性セットへの参照を提供します。
• 権限:発行者は、発行されたトークンのクレーム値セットの権限を持ちます (通常の管理カードまたは個人カードと同様)。
• 編集可能性:基礎となる属性の値 (resource-udi クレームによって参照される) は、発行者以外の当事者によって編集できる場合があります。
• サポートされている属性: r-card の resource-udi クレームの値は、データ エンティティ (人、組織、またはその他のオブジェクトを表す) を「指す」エンティティ UDI ^[8] (URI) です。このデータ エンティティの属性セットは、上記の「サポートされているクレーム」とは異なります (通常はそのスーパーセットです)。

概念的には、マネージド カードは基本的に、セキュリティ トークンを要求できる Web サービス ( STSなど) であるトークン サービスへの人間に優しい「ポインタ」です。セキュリティ トークンは、発行者 (権限として機能するトークン サービス) によって暗号的に署名された、ある当事者に関する一連の属性アサーション (クレームとも呼ばれます) です。r カードには、属性値が (i) r カードのすべての当事者によって共有され、(ii) r カード発行者の STS によって消費される基礎となる属性を形成し、この STS が行うクレームの値を提供するデータ エンティティを指す 2 番目の「ポインタ」が含まれています。r カードにこの 2 番目の「ポインタ」を含めることで、r カードの所有者は、これらの基礎となる属性の一部にアクセスして更新できるようになります。カード発行者は、アクセス制御ポリシーを維持して、誰がどのレベルのアクセスを持つかを制御します。

この2番目のポインタはエンティティUDI ^[8]です。これは、ヒギンズコンテキストデータモデル^[9]内のエンティティオブジェクトへの参照です。エンティティUDIは、ヒギンズプロジェクトのアイデンティティ属性サービス^[10 ]を使用して逆参照され、基礎となるエンティティの属性にアクセスできます。解決されると、このサービスの消費者はエンティティの属性を検査し、場合によっては変更したり、 Webオントロジー言語(OWL)で記述されたスキーマを取得したりできます。

r カードによって参照されるデータ エンティティには、文字列や数値などの基本的な ID 属性値に加えて、基本属性タイプの集約と他のエンティティへの UDI リンクで構成される複雑な属性値を設定できます。

情報カードは、サイトへのログインに使用されるだけでなく、他の種類のやり取りにも使用できます。情報カード モデルは、カードを使用して、アイデンティティ プロバイダーから信頼当事者に、両者にとって意味があり、かつ本人が公開しても構わないあらゆる情報を伝達できるため、非常に柔軟です。i-card で伝送されるデータ要素はクレームと呼ばれます。

クレームの考えられる用途の 1 つはオンラインでの年齢確認です。アイデンティティ プロバイダーが年齢証明カードを提供し、RP がそれをオンラインでのワイン販売などの目的で受け入れます。他の属性も検証できます。もう 1 つはオンライン支払いです。この場合、商人は支払いに必要な最小限の情報のみを含むオンライン支払いカードを支払い発行者から受け入れることができます。クレームによって伝達されるロール ステートメントは、依存当事者によるアクセス制御の決定に使用できます。

アイデンティティ メタシステム コンポーネントを構築するために必要なプロトコルは、ライセンス費用なしで誰でもあらゆる目的で使用でき、公開されているドキュメントのみを使用して相互運用可能な実装を構築できます。Microsoft、^[11] 、 IBM、^[12]などによって特許が発行されており、アイデンティティ メタシステムの基盤となるプロトコルは誰でも自由に使用できます。

Identity Selector Interoperability Profile v 1.5 ^[3] (または OASIS IMI v1.0 委員会草案) ^[4]で定義されている情報カードは、オープンで相互運用可能な通信標準に基づいています。相互運用可能な i-card コンポーネントは、Windows、Mac OS、Linux などのプラットフォーム向けに数十の企業やプロジェクトによって構築されており、携帯電話用のプロトタイプ実装もあります。これらのコンポーネントを組み合わせることで、相互運用可能な Identity Metasystem が実装されます。情報カードは、Web サイトと Web サービス アプリケーションの両方に ID を提供するために使用できます。

^{i-cardの相互運用性テストイベントはOSIS [13]}とBurton Group ^[14]がスポンサーとなって何回か開催されており、そのうちの1つは2007年10月にバルセロナで開催されたEuropean Catalyst ConferenceのInterop ^[15]で、最も最近のものはRSA 2008で開催されました。これらのイベントは、アイデンティティメタシステムの多数の参加者によって構築されているさまざまな情報カードソフトウェアコンポーネントが互いにうまく機能することを保証するのに役立っています。

アイデンティティセレクタ相互運用性プロファイルv1.5 ^[3] (またはOASIS IMI v1.0委員会草案) ^[4]に基づく情報カード実装を構築するために必要なプロトコルは、誰でもあらゆる目的で無料で使用でき、公開されているドキュメントのみを使用して相互運用可能な実装を構築できます。Microsoft、^[11]、 IBM、^[12]などによって特許が約束されており、この情報カード技術は誰でも自由に利用できます。

2008 年 6 月、Equifax、Google、Microsoft、Novell、Oracle、PayPal などの業界リーダーは、企業とインターネットの両方にまたがるオープンで相互運用可能なロイヤリティフリーのユーザー中心の ID レイヤーの主要コンポーネントとして情報カード メタファーの使用を推進するために、情報カード 財団を設立しました。

2007年6月にサンフランシスコで開催されたCatalystカンファレンスでのInteropに関するレポートで、アナリストのボブ・ブレイクリーは次のように書いています。 ^[16]

相互運用イベントは、ユーザー中心のアイデンティティ技術の成熟におけるマイルストーンでした。イベント前には、いくつかの仕様、1 つの商用製品、および多数のオープンソース プロジェクトがありました。イベント後、アイデンティティ メタシステムが稼働していると言っても過言ではありません。

「情報カード」という用語は、Microsoft が 2005 年 5 月に、近々リリースされる Windows CardSpace ソフトウェアで導入される視覚的な情報カードのメタファーの名前として導入しました。2006 年初頭まで、情報カードは「InfoCard」というコード名で呼ばれることもありましたが、これは誰でも自由に使用できる名前ではありませんでした。情報カードという名前は、製品や実装に関係なく、誰でも自由に使用できる名前として特に選ばれました。「情報カード」という名前は商標登録されておらず、商標登録できないほど一般的な名前です。

i-cardという用語は、2006年6月21日のBerkman/MIT Identity Mashupカンファレンスで導入されました。^{[17] [18]}その目的は、業界のTMやその他のIPやアーティファクトに関連付けられていない用語を定義することでした。当時、Microsoftは、Windows CardSpaceの基礎となるプロトコルにOpen Specific Promise ^[11]の適用をまだ完了しておらず、情報カードという用語はすべての人が自由に使用できるわけではないという誤解もあったため、保守的にi-cardという用語が導入されました。

^{マイクロソフト社のマイク・ジョーンズ氏は、IIW 2007b [19]}のセッションの参加者に対し、マイクロソフトは情報カードという用語があらゆる種類の情報カードを表すために一般的に使用され、すべての人が自由に使用できることを常に意図していたと説明し、この用語がマイクロソフトが最初に定義した種類の情報カードにのみ適用される可能性があるという以前の誤解を正そうとしました。彼は、異なる用語を使用する法的または技術的な理由は残っていないため、同じ意味を持つ 2 つの用語を使用するよりも、すべての人が情報カードという共通用語を使用する方が業界にとって有益であると主張しました。この場合、e-mail が電子メールの短縮形になったのと同じように、i-card という用語は情報カードの短縮形になります。

• DACS – Cで書かれたオープンソースのRPおよび情報カード STS
• Higgins プロジェクト– Identity Selector のデプロイメント構成
• Windows CardSpace – Windows Vista、Windows XP、Windows Server 2003で実行されました

• デジタルアイデンティティ
• 情報カード財団
• オープンID
• サムエル

• Clique Space: アイデンティティの新たな見方、Owen Thomas、2010 年 11 月。
• Parity が無料のオンライン ID 管理を提供 – 2008 年 10 月CNET記事、Robert Vamosi 著
• Microsoft のアイデンティティ メタシステムに対するビジョン、Michael B. Jones、2005 年 5 月。
• アイデンティティの法則、キム・キャメロン、2005 年 5 月。
• アイデンティティ メタシステム アーキテクチャの設計原理、Kim Cameron および Michael B. Jones、2006 年 1 月。
• 7 つのアイデンティティ法: デジタル時代におけるプライバシーを組み込んだアイデンティティ法の事例、アン・カヴォーキアン、オンタリオ州情報プライバシーコミッショナー、2006 年 10 月。

• テクノロジーリーダーはパスワードよりもオンラインIDカードを好む – ニューヨークタイムズ紙の記事 2008年6月24日情報カード財団の設立を発表
• Identity Selector 相互運用性プロファイル、Arun Nanda、2007 年 4 月。
• アイデンティティセレクタ相互運用性プロファイル v 1.5
• OASIS IMI v1.0 委員会草案
• Identity Selector 相互運用性プロファイル V1.0 実装者ガイド、Microsoft Corporation および Ping Identity Corporation、2007 年 4 月。
• Web アプリケーションおよびブラウザー内での Identity Selector Interoperability Profile V1.0 の使用ガイド、Michael B. Jones、2007 年 4 月。
• アイデンティティ メタシステム アーキテクチャの設計原理、Kim Cameron および Michael B. Jones、2006 年 1 月。
• Web サイトでの情報カードのサポートパターン: サインアップとサインイン用の個人カード、Bill Barnes、Garrett Serack、James Causey、2007 年 8 月。
• Microsoft Open Specific Promise、2007 年 5 月。
• IBM 相互運用性仕様誓約、2007 年 7 月。

• 情報カード財団 2013年2月4日アーカイブウェイバックマシン
• 情報カードアイコンのお知らせ、2007 年 6 月。
• オープンソースアイデンティティシステム (OSIS) 2008年5月16日アーカイブ、Wayback Machine