JP6582898B2 - 情報提供システム、情報提供プログラム、及び情報提供方法 - Google Patents

Description

本発明は、情報提供システム、情報提供プログラム、及び情報提供方法に関する。

近年、複数のwebサービスを連携させて新たなサービスを提供するサービス連携が普及しつつある。そのようなサービス連携としては、例えばTwitter（登録商標）でつぶやいたデータをFacebook（登録商標）へ反映させるサービスがある。このサービスではTwitterからFacebookにデータを渡してもよいとの同意をユーザから取得する必要があり、これを実現するために例えばOAuthプロトコルが使用される。

この他に、あるwebサービスのユーザ認証を別のサービスが代理で行う認証連携と呼ばれるサービス形態もある。代理でユーザ認証を行うサービス事業者は、IdP(Identity Provider)と呼ばれ、認証が成功した場合には依頼元に住所や氏名等のユーザの属性情報を提供する。

一方、IdPに認証を依頼するサービス事業者は、RP(Relying Party)と呼ばれ、認証が成功した際にIdPから提供されるユーザの属性情報を利用して当該ユーザにサービスを提供する。

この認証連携においては、IdPからRPにユーザの属性情報を渡してもよいとの同意をユーザから取得する必要があり、これを実現するためのプロトコルとしてOpenID ConnectやSAML(Security Assertion Markup Language)がある。

特開２０１３−８８９０１号公報

ところで、前述のサービス連携や認証連携が混在する場合には、サービス間でユーザの複数の属性情報が受け渡される場面が想定される。

しかしながら、その場合には属性情報の受け渡しをするたびにユーザに同意を求める必要があるため、ユーザが複数の同意をしなければならず、同意に伴うユーザの負担が増す。

一つの側面では、本発明は、同意に伴うユーザの負担を軽減することを目的とする。

一つの側面では、本発明は、第１の情報処理装置、第２の情報処理装置、及び第３の情報処理装置を備えた情報提供システムであって、前記第１の情報処理装置は、前記第３の情報処理装置が保有するユーザの属性情報を取得することについての承認を求める承認依頼を前記第２の情報処理装置に通知し、前記属性情報の取得について前記ユーザの同意が得られたことを示す同意識別子が前記第２の情報処理装置から通知されたときに、前記同意識別子を前記第３ の情報処理装置に通知する第１の通知部、を有し、前記第２の情報処理装置は、前記第３の情報処理装置からの依頼を受けて、前記第３の情報処理装置から通知された前記同意識別子の正当性を確認する確認部と、前記承認依頼を受けたときに前記属性情報を前記第１の情報処理装置に提供することについての前記同意を前記ユーザに要求し、前記同意が得られたときに前記同意識別子を前記第１の情報処理装置に通知する第２の通知部と、を有し、前記第３の情報処理装置は、複数の前記属性情報を記憶した記憶部と、通知された前記同意識別子の前記正当性についての確認を前記第２の情報処理装置に依頼する依頼部と、前記確認部によって前記正当性が確認されたときに、複数の前記属性情報のうち、提供を許可する属性情報を特定するアクセストークンを前記第１の情報処理装置へ通知し、前記第１の情報処理装置からの前記アクセストークンの通知を受けて、前記アクセストークンによって特定される属性情報を前記第１の情報処理装置に通知し、前記正当性が確認されないときには前記第１の情報処理装置に前記属性情報を通知しない第３の通知部、を有する情報提供システムが提供される。

同意に伴うユーザの負担を軽減することができる。

図１は、サービス連携と認証連携とが混在したシステムについて模式的に示す図である。 図２は、サービス連携と認証連携とが混在したシステムにおける処理の流れについて説明するためのシーケンス図（その１）である。 図３は、サービス連携と認証連携とが混在したシステムにおける処理の流れについて説明するためのシーケンス図（その２）である。 図４は、サービス連携と認証連携とが混在したシステムにおいて、同意要求をまとめた場合の処理の流れについて説明するためのシーケンス図（その１）である。 図５は、サービス連携と認証連携とが混在したシステムにおいて、同意要求をまとめた場合の処理の流れについて説明するためのシーケンス図（その２）である。 図６は、第１実施形態に係る情報提供システムの全体構成例を示す図である。 図７は、第１実施形態における第１〜第３の情報処理装置と端末の各々の機能構成例を示す図である。 図８は、第１実施形態における同意テーブルの一例を示す図である。 図９は、第１実施形態に係る情報提供システムの動作の一例を示すシーケンス図（その１）である。 図１０は、第１実施形態に係る情報提供システムの動作の一例を示すシーケンス図（その２）である。 図１１は、第１実施形態における許可応答の一例を示す図である。 図１２は、第１実施形態における第２の情報処理装置の処理内容について示すフローチャート（その１）である。 図１３は、第１実施形態における第２の情報処理装置の処理内容について示すフローチャート（その２）である。 図１４は、第１実施形態における第２の情報処理装置の処理内容について示すフローチャート（その３）である。 図１５は、第１実施形態における第２の情報処理装置の処理内容について示すフローチャート（その４）である。 図１６は、第２実施形態に係る情報提供システムの動作の一例を示すシーケンス図（その１）である。 図１７は、第２実施形態に係る情報提供システムの動作の一例を示すシーケンス図（その２）である。 図１８は、第２実施形態に係る同意テーブルの一例を示す図である。 図１９は、CSRF攻撃について説明するためのシーケンス図 図２０は、第１及び第２実施形態に係る情報提供プログラムを実行するコンピュータのハードウェア構成図である。

本実施形態の説明に先立ち、サービス連携と認証連携とが混在したシステムについて説明する。

図１は、サービス連携と認証連携とが混在したシステムについて模式的に示す図である。

このシステム１０は、第１〜第３の情報処理装置１〜３と、ユーザが操作する端末４とを有しており、第１〜第３の情報処理装置１〜３が連携して新たなサービスをユーザに提供する。

以下では、RP(Relying Party)が第１の情報処理装置１を用いてクラウドソーシング等のサービスを提供し、IdP(Identity Provider)が第２の情報処理装置２を用いて認証サービスを行う場合を想定する。

このうち、第２の情報処理装置２は、ユーザの属性情報７が記憶された記憶部２ａを有しており、認証が成功した場合には第１の情報処理装置１にユーザの属性情報７を提供する。

そして、第３の情報処理装置３は、ユーザの過去の履歴を第１の情報処理装置１に提供する履歴サービスに使用され、ユーザの属性情報８として履歴が記憶された記憶部３ａを有する。このように履歴サービスを行うサービス事業者はAP(Attribute Provider)と呼ばれる。

各属性情報７、８は特に限定されない。以下では、ユーザに関連する任意の情報を属性情報７、８と呼ぶ。

例えば、属性情報７には、ユーザの氏名、住所、生年月日、及びメールアドレスが含まれるものとする。また、属性情報８には、ユーザが過去に取得したTOEIC(Test of English for International Communication：登録商標)等の語学スコア記録証や看護師免許等の資格情報が含まれるものとする。

また、第１の情報処理装置１と第２の情報処理装置２との間や、第２の情報処理装置２と第３の情報処理装置３との間の通信プロトコルはOpenID connectであり、第１の情報処理装置１と第３の情報処理装置３との間の通信プロトコルはOAuth 2.0であるとする。

次に、第１〜第３の情報処理装置１〜３が連携して提供するサービスの一例について説明する。

この例では、第１の情報処理装置１が翻訳アルバイトの募集をしており、ユーザがそのアルバイトに応募することを考える。

アルバイトに応募するため、ユーザは、端末４を操作することにより第１の情報処理装置１にサービス要求９を通知する。

サービス要求９を受けた第１の情報処理装置１は、ユーザと連絡を取るために、第２の情報処理装置２が保有する属性情報７としてメールアドレスを要求する。このとき、第２の情報処理装置２は、メールアドレスを第１の情報処理装置１に提供してよいとの同意をユーザから得るために、端末４に対して同意要求１１を通知する。

また、第３の情報処理装置３は、属性情報８として語学スコア記録証を保有しているものとする。そして、その記録証がユーザのものであるかどうかを確認するために、第３の情報処理装置３は第２の情報処理装置２に対して属性情報７のうち氏名と住所とを要求する。

このとき、第２の情報処理装置２は、氏名と住所とを第３の情報処理装置３に提供してよいとの同意をユーザから得るために、端末４に対して同意要求１２を通知する。

更に、第３の情報処理装置３は、第１の情報処理装置１に対して属性情報８として語学スコア記録証を提供する。このとき、第３の情報処理装置３は、語学スコア記録証を第１の情報処理装置１に提供してよいとの同意をユーザから得るために、端末４に対して同意要求１３を通知する。

このように、この例では同意要求１１〜１３の三つの全てにユーザが同意しなければならず、ユーザの負担が大きい。

同意に伴うユーザの負担を減らすには、これらの同意要求１１〜１３を単純に一つにまとめればよいと考えられる。これが可能かどうかを検討するため、次に同意要求１１〜１３がOpenID ConnectとOAuth 2.0のそれぞれのプロトコルにおいてどのように通知されるのかについて説明する。

図２及び図３は、システム１０における処理の流れについて説明するためのシーケンス図である。

なお、図２及び図３において、実線で示す処理はOpenID Connectに即した処理を示し、一点鎖線で示す処理はOAuth 2.0に即した処理を示す。また、点線で示す処理は、これらのプロトコルで規定されていない処理を示す。

また、図２及び図３において、図１で説明したのと同じ要素には図１におけるのと同じ符号を付し、以下ではその説明を省略する。

以下、図２及び図３に示す処理をステップ番号に沿って説明する。

(S1)まず、第１の情報処理装置１が募集している翻訳アルバイトに応募するために、ユーザが端末４を操作することにより、第１の情報処理装置１にサービス要求９を通知する。

(S2)そのサービス要求９を受けて、第１の情報処理装置１が第２の情報処理装置２に対して許可要求を通知する。

この許可要求は、HTTP(Hypertext Transfer Protocol)リクエストであって、端末４により第２の情報処理装置２にリダイレクトされる。

また、そのHTTPヘッダにはscopeパラメータが設定される。scopeパラメータは、第２の情報処理装置２が保有している複数の属性情報７のうち、第１の情報処理装置１が要求するものを特定するパラメータである。本ステップでは、そのscopeパラメータに、複数の属性情報７のうち当該ユーザのメールアドレスを指定する。

(S3)第２の情報処理装置２は、ユーザが第２の情報処理装置２を利用する権限があるかを確認するための認証を行う。

この認証は、例えばパスワード認証で行われ、ユーザが端末３を介して自分の認証IDであるA_IDとパスワードPWとを第２の情報処理装置２に送信することで行われる。

(S4)ステップS3の認証が成功した場合、属性情報７（メールアドレス）を第１の情報処理装置１に提供してよいとの同意をユーザから得るために、第２の情報処理装置２が端末４に同意要求１１を通知する。

(S5)ユーザは、属性情報７（メールアドレス）の提供に同意するときは、端末４を操作して第２の情報処理装置２に同意を通知する。

(S6)ステップS5で同意を受けたとき、第２の情報処理装置２は、ステップS2の許可要求に対する応答として、第１の情報処理装置１に許可応答を返す。その許可応答は、HTTPレスポンスであって、端末４によりリダイレクトされて第１の情報処理装置１に通知される。

また、この許可応答には許可コード(Authorization Code)が付加される。許可コードは、第２の情報処理装置２が生成した記号列であって、HTTPレスポンスのLocationヘッダに指定される。また、許可コードは、属性情報７（メールアドレス）の提供を受けるためのアクセストークンと後で交換される。

(S7)第１の情報処理装置１は、第２の情報処理装置２に対してアクセストークン要求を通知する。アクセストークン要求は、第２の情報処理装置２から属性情報７（メールアドレス）を得る際に必要となるアクセストークンを要求するHTTPリクエストである。

また、そのHTTPヘッダのgrant_typeパラメータには、前述の許可コードが格納される。

(S8)第２の情報処理装置２は、そのアクセストークン要求に含まれている許可コードを検証する。

そして、検証に成功した場合には、第２の情報処理装置２が第１の情報処理装置１にアクセストークン応答を返す。

アクセストークン応答は、許可コードと引き換えにアクセストークンを第１の情報処理装置１に渡すためのHTTPレスポンスである。アクセストークンは、第２の情報処理装置２が生成した記号列であって、HTTPヘッダのaccess_tokenパラメータに指定される。

また、アクセストークンは、第２の情報処理装置２が所有する複数の属性情報７のうちの一つを特定するためのIDとしての機能も兼ねる。

なお、有効期限が切れたアクセストークンの代替となるリフレッシュトークンもアクセストークン応答に含めてもよい。これについては、後述の各アクセストークン応答でも同様である。

(S9)第１の情報処理装置１は、第２の情報処理装置２にアクセストークンを渡すことにより、第２の情報処理装置２にデータ要求を通知する。この場合に要求するデータは、前述のようにユーザの属性情報７（メールアドレス）である。

また、このデータ要求はHTTPリクエストであって、そのHTTPヘッダのaccess_tokenパラメータに上記のアクセストークンが指定される。

(S10)第２の情報処理装置２は、第１の情報処理装置１から渡されたアクセストークンと、自身がステップS8で発行したアクセストークンとの同一性を確認する。

そして、両者の同一性が確認できた場合には、第２の情報処理装置２は、そのアクセストークンが示すIDに対応する属性情報７（メールアドレス）を特定する。その後、その属性情報７（メールアドレス）をデータ応答に乗せて第２の情報処理装置２に通知する。

ここまでのステップにより、第１の情報処理装置１が属性情報７（メールアドレス）を取得できたことになる。

次に、第１の情報処理装置１は、以下のようにして第３の情報処理装置３が保有する属性情報８（語学スコア記録証）の取得を試みる。

(S11)まず、第１の情報処理装置１が第３の情報処理装置３に対して許可要求を通知する。

この許可要求は、第３の情報処理装置３が保有している属性情報８（語学スコア記録証）の提供を要求するHTTPリクエストであり、端末４から第３の情報処理装置３にリダイレクトされる。

また、第３の情報処理装置３が保有している複数の属性情報８のうち、第１の情報処理装置１が要求する情報が当該ユーザの語学スコア記録証であることを特定するために、HTTPヘッダのscopeパラメータにはその語学スコア記録証が指定される。

(S12)第３の情報処理装置３は、語学スコア記録証がユーザ本人のものであることを確認するための属性情報７（氏名、住所）を第２の情報処理装置２から取得すべく、その属性情報７（氏名、住所）の提供を要求する許可要求を第２の情報処理装置２に通知する。

この許可要求もHTTPリクエストであり、端末４から第２の情報処理装置２にリダイレクトされる。

更に、第２の情報処理装置２が保有している複数の属性情報７のうち、第３の情報処理装置３が要求する情報が当該ユーザの氏名と住所であることを特定するために、HTTPヘッダのscopeパラメータにはその氏名と住所が指定される。

(S13)第２の情報処理装置２は、属性情報７（氏名、住所）を第３の情報処理装置３に提供してよいとの同意をユーザから得るために、端末４に同意要求１２を通知する。

(S14)ユーザは、属性情報７（氏名、住所）の提供に同意するときは、端末４を操作して第２の情報処理装置２に同意を通知する。

(S15)ステップS14でユーザの同意が得られた場合には、第２の情報処理装置２は、ステップS12の許可要求に対する応答として第３の情報処理装置３に許可応答を返す。この許可応答もHTTPレスポンスであり、端末４により第３の情報処理装置３にリダイレクトされる。

また、その許可応答のLocationヘッダには、第２の情報処理装置２が生成した記号列が許可コードとして指定される。その許可コードは、属性情報７（氏名、住所）の提供を受けるためのアクセストークンと後で交換される。

(S16)第３の情報処理装置３は、第２の情報処理装置２に対してアクセストークン要求を通知する。このアクセストークン要求は、第２の情報処理装置２から属性情報７（氏名、住所）を得る際に必要となるアクセストークンを要求するHTTPリクエストである。

また、そのアクセストークンのHTTPヘッダのgrant_typeフィールドには、ステップS15で第２の情報処理装置２が発行した許可コードが格納される。

(S17)第２の情報処理装置２は、そのアクセストークンに含まれている許可コードを検証し、検証に成功した場合には第３の情報処理装置３にアクセストークン応答を返す。

アクセストークン応答は、許可コードと引き換えにアクセストークンを第３の情報処理装置３に渡すためのHTTPレスポンスである。そして、第２の情報処理装置２が生成した記号列で表されるアクセストークンが、HTTPヘッダのaccess_tokenパラメータに指定される。

このアクセストークンは、第２の情報処理装置２が所有する複数の属性情報７のうちの一つを特定するためのIDとしての機能も兼ねる。

(S18)第３の情報処理装置３は、アクセストークンを第２の情報処理装置２に渡すことにより、第２の情報処理装置２にデータ要求を通知する。この場合に要求するデータは、前述のようにユーザの属性情報７（氏名、住所）である。

(S19)第２の情報処理装置２は、第３の情報処理装置３から渡されたアクセストークンと、自身がステップS17で発行したアクセストークンとの同一性を確認する。

そして、その同一性が確認できた場合には、第２の情報処理装置２は、アクセストークンが示すIDに対応した属性情報７（氏名、住所）を特定する。その後、その属性情報７（氏名、住所）をデータ応答に乗せて第３の情報処理装置３に通知する。

ここまでのステップにより、第３の情報処理装置３が属性情報７（氏名、住所）を取得できたことになる。

(S20)第３の情報処理装置３は、属性情報８（語学スコア記録証）を第３の情報処理装置３に提供してよいとの同意をユーザから得るために、端末４に同意要求１３を通知する。

(S21)ユーザは、属性情報８（語学スコア記録証）の提供に同意するときは、端末４を操作して第３の情報処理装置３に同意を通知する。

(S22)ステップS21で同意が得られたときは、第１の情報処理装置１は、ステップS11の許可要求に対する応答として第１の情報処理装置１に許可応答を返す。この許可応答もHTTPレスポンスであり、端末４により第１の情報処理装置１にリダイレクトされる。

また、このHTTPレスポンスのLocationヘッダには、第３の情報処理装置３が生成した記号列が許可コードとして格納される。この許可コードは、属性情報８（語学スコア記録証）の提供を受けるためのアクセストークンと後で交換される。

(S23)第１の情報処理装置１は、第３の情報処理装置３に対してアクセストークン要求を通知する。このアクセストークン要求は、第３の情報処理装置３から属性情報８（語学スコア記録証）を得る際に必要となるアクセストークンを要求するHTTPリクエストである。

また、そのアクセストークンのHTTPヘッダのgrant_typeフィールドには、ステップS22で第３の情報処理装置３が発行した許可コードが格納される。

(S24)第３の情報処理装置３は、そのアクセストークンに含まれている許可コードを検証し、検証に成功した場合には第１の情報処理装置１にアクセストークン応答を返す。

アクセストークン応答は、許可コードと引き換えにアクセストークンを第１の情報処理装置１に渡すためのHTTPレスポンスである。そして、第３の情報処理装置３が生成した記号列で表されるアクセストークンが、そのHTTPレスポンスのaccess_tokenパラメータに指定される。

そのアクセストークンは、第３の情報処理装置３が所有する複数の属性情報８（語学スコア記録証）のうちの一つを特定するためのIDとしての機能も兼ねる。

(S25)第１の情報処理装置１は、アクセストークンを第３の情報処理装置３に渡すことにより、第３の情報処理装置３にデータ要求を通知する。この場合に要求するデータはユーザの属性情報８（語学スコア記録証）である。

(S26)第３の情報処理装置３は、第１の情報処理装置１が提示したアクセストークンと、自身がステップS24で発行したアクセストークンとの同一性を確認する。

そして、両者の同一性が確認できた場合には、第３の情報処理装置３は、アクセストークンが示すIDに対応した属性情報８（語学スコア記録証）を特定する。その後、その属性情報８（語学スコア記録証）をデータ応答に乗せて第１の情報処理装置１に通知する。

ここまでのステップにより、第１の情報処理装置１が属性情報８（語学スコア記録証）を取得できたことになる。

(S27)第１の情報処理装置１は、ユーザの属性情報８（語学スコア記録証）に基づいて、翻訳アルバイトの採用の可否を決定し、その結果をサービス応答として端末４に通知する。

以上により、このシステム１０における基本処理を終了する。

上記したように、ユーザが同意すべき同意要求１１〜１３は、ステップS4、S13、S20においてユーザに通知される。これらの複数の同意要求１１〜１３にいちいち同意するのはユーザにとって煩わしい。

そこで、これらの同意要求１１〜１４をステップS4にまとめることで、ユーザの負担を減らすことを考える。

図４及び図５は、このように同意要求をまとめた場合の処理の流れについて説明するためのシーケンス図である。なお、図４及び図５において、図２及び図３で説明したのと同じ要素とステップには同じ符号を付し、以下ではその説明を省略する。

以下では、第１〜第３の情報処理装置１〜３の各々を使用するサービス事業者間で予め契約等の取り決めをしておくことで、どの情報処理装置にどの属性情報を提供するのかが事前に決められているものとする。

例えば、属性情報７のメールアドレスを第１の情報処理装置１に提供することと、属性情報７の氏名と住所とを第３の情報処理装置３に提供することが事前に決められているものとする。また、属性情報８の語学スコア記録証を第１の情報処理装置１に提供することも事前に決められているものとする。

このように事前に決めておくことで、第２の情報処理装置２は、ステップS2の許可要求を受けた時点で、後で同意要求１１〜１３を通知する必要があると判断できる。

そこで、第２の情報処理装置２は、ステップS4においてユーザに同意要求１１を要求する際に、残りの同意要求１２、１３も合わせてユーザに要求し、ステップS13、S14、S20、S21はスキップする。

また、ユーザは、これら三つの同意要求１１〜１３について同意するか否かをステップS5で一度に判断する。

そして、三つの同意要求１１〜１３の全てに同意する場合のみ、ステップS5においてユーザが第２の情報処理装置２に同意を通知する。

その同意を受けた第２の情報処理装置２は、ユーザが提供に同意した属性情報７、８を同意済み属性として記憶しておく。この例では、属性情報７（メールアドレス、氏名、住所）と属性情報８（語学スコア記録証）とが同意済み属性として記憶される。

そして、ステップS6の許可応答において、第２の情報処理装置２が第１の情報処理装置１に対して同意済み属性（メールアドレス、氏名、住所、語学スコア記録証）を通知する。その通知を受けた第１の情報処理装置１は、当該通知に含まれる同意済み属性（メールアドレス、氏名、住所、語学スコア記録証）をステップS11の許可要求のscopeパラメータに指定することで、最終的にステップS26でその属性を第３の情報処理装置３から取得できる。

以上説明したような処理によれば、ステップS4において三つの同意要求１１〜１３を一度にユーザに通知したことで、ステップS5においてユーザが一度に同意を通知でき、ユーザの負担軽減を図ることができる。

しかし、この処理には次のようなセキュリティ上の問題がある。

例えば、悪意のある第１の情報処理装置１が、ステップS11の許可要求のscopeパラメータに、同意済み属性（メールアドレス、氏名、住所、語学スコア記録証）には含まれないユーザが未同意の属性情報８（例えば看護師免許）を指定する可能性がある。この場合には、第３の情報処理装置３が保有する属性情報８のうち、ユーザが同意していない情報を第１の情報処理装置１が不正に取得することになる。

以下に、このようなセキュリティ上の問題を解決しつつ、ユーザに複数の同意を要求することがない各実施形態について説明する。

（第１実施形態）
図６は、第１実施形態に係る情報提供システムの全体構成例を示す図である。

図６に示すように、この情報提供システムは、第１〜第３の情報処理装置３１〜３３と端末３４とを有しており、これらがネットワーク３６を介して相互に接続される。

このうち、第１の情報処理装置３１は例えばユーザにサービスを提供するRPが使用し、第２の情報処理装置３２は例えば代理でユーザ認証を行うIdPが使用する。そして、第３の情報処理装置３３は、ユーザの属性を提供するAPが使用する。

各情報処理装置の数は特に限定されず、第１の情報処理装置３１と第３の情報処理装置３３の数はそれぞれ複数であってもよい。

また、端末３４は、ユーザが操作することにより第１の情報処理装置３１からサービスを受けるものであって、例えばPC(Personal Computer)、タブレット端末、及びスマートフォン等である。

端末３４の数も特に限定されず、ユーザの人数に応じて複数の端末３４を設けてもよい。

そして、これらの各部を接続するネットワーク３６としては、例えばインターネット、LAN(Local Area Network)、WAN(Wide Area Network)、及びVPN(Virtual Private Network)等を採用し得る。

図７は、第１〜第３の情報処理装置３１〜３３と端末３４の各々の機能構成例を示す図である。

図７に示すように、端末３４は、ネットワーク３６上の情報リソースを扱うためのwebブラウザ３５を有する。

一方、第１の情報処理装置３１は、第１のメッセージ制御部４１と、連携管理部４２と、サービスアプリケーション４３と、第１の記憶部４４とを有する。

このうち、第１メッセージ制御部４１は、第１の通知部の一例であって、OAuthやOpenID Connect等の通信プロトコルに従って他の装置との間でメッセージの送受信を行う。

例えば、第１のメッセージ制御部４１は、第３の情報処理装置３３が保有するユーザの後述の属性情報３８を取得することについての承認を求める承認依頼を第２の情報処理装置３２に通知する。また、第１のメッセージ制御部４１は、属性情報３８の取得についてユーザの同意が得られたことを示す後述の同意IDが第２の情報処理装置３２から通知されたときに、その同意IDを第３の情報処理装置３３に通知する。

一方、連携管理部４２は、第１〜第３の情報処理装置３１〜３３のうちのどれがサービスの連携に関与するのかを特定する連携IDを前述の承認依頼に付加する。

また、サービスアプリケーション４３は、ネットワーク３６を介してユーザにサービスを提供するプログラムである。そのサービス内容は特に限定されない。以下では、サービスアプリケーション４３が翻訳アルバイトを募集するサービスを提供する場合について説明する。

また、第１の記憶部４４は、第１のメッセージ制御部４１が受信した前述の同意IDを記憶する。

一方、第２の情報処理装置３２は、第２のメッセージ制御部５１、認証部５２、第２の記憶部５３、制御部５４、及び同意テーブル５５を有する。

このうち、第２のメッセージ制御部５１は、第２の通知部の一例であって、OpenID Connectに従って他の装置との間でメッセージの送受信を行う。

例えば、第２のメッセージ制御部５１は、第１の情報処理装置３１から前述の承認依頼を受けたときに、属性情報３８を第１の情報処理装置３１に提供することについての同意をユーザに要求する。そして、その同意が得られたときに、第１の情報処理装置３１は同意IDを第１の情報処理装置３１に通知する。

また、認証部５２は、前述の承認依頼を受けたときに、第１の情報処理装置３１や第３の情報処理装置３３の代わりにユーザの認証を行う。認証方法は特に限定されず、例えばパスワード認証で認証を行い得る。

そして、第２の記憶部５３には、ユーザ認証に必要なユーザIDとパスワード等の認証情報３９が予め登録される。

その他に、ユーザの氏名、住所、及びメールアドレス等の複数の属性情報３７も認証テーブル５３に格納される。なお、属性情報３７はこれらに限定されない。以下では、ユーザに関連する任意の情報を属性情報３７と呼ぶ。

制御部５４は、ユーザが同意していない属性情報３８が第１の情報処理装置３１に取得されるのを防ぐ機能を有し、前述の同意IDを生成する生成部５４ａと、その同意IDの正当性を確認する確認部５４ｂとを有する。

そして、同意テーブル５５は、同意IDの正当性を確認するのに使用されるものであって、例えば図８のような属性を有する。

図８は、同意テーブル５５の一例を示す図である。

この例では、同意テーブル５５には、「同意ID」、「ユーザセッション」、「連携ID」、「連携元」、及び「状態チェックフラグ」の各属性が設定される。

このうち、「同意ID」は、各情報処理装置３１〜３３を流れるメッセージに一意に付加される記号列であって、同意識別子の一例である。

確認部５４ｂ（図７参照）は、後述のように同意テーブル５５に同意IDが存在するかを確認し、その確認を終了した場合には「状態チェックフラグ」が「１」とし、確認が行われていない場合には状態チェックフラグが「０」とする。

また、「ユーザセッション」は、第２の情報処理装置３２と端末３４との間で確立されたセッションである。そして、「連携ID」は、第１〜第３の情報処理装置３１〜３３のうち、どの情報処理装置が連携してユーザにサービスを提供するのかを特定するIDであって、連携識別子の一例である。

更に、「連携元」は、OAuthやOpenID Connectプロトコルに従って第２の情報処理装置３２に対して前述の承認依頼を通知してきた要求元の情報処理装置を示す。

再び図７を参照する。

第３の情報処理装置３３は、第３のメッセージ制御部６１、第３の記憶部６２、サービスアプリケーション６３、及び管理部６４を有する。

このうち、第３の記憶部６２は、ユーザの複数の属性情報３８を記憶する。その属性情報３８は、例えばユーザが過去に取得した資格等であり、語学スコア記録証や看護師免許等が含まれる。なお、属性情報３８はこれらに限定されず、ユーザに関連する任意の情報を属性情報３８とし得る。

また、第３のメッセージ制御部６１は、第３の通知部の一例であって、OAuthやOpenID Connect等の通信プロトコルに従って他の装置との間でメッセージの送受信を行う。

また、サービスアプリケーション６３は、第３の記憶部６２に記憶されている属性情報３８を第１の情報処理装置３１に提供するプログラムである。例えば、サービスアプリケーション６３は、ユーザの過去の履歴として属性情報３８に含まれる語学スコア記録証や看護師免許を提供する履歴サービスを実現するプログラムである。

そして、管理部６４は、ユーザが同意していない属性情報３８が第１の情報処理装置３１に取得されるのを防ぐ機能を有し、依頼部６４ａと判断部６４ｂとを有する。

このうち、依頼部６４ａは、第１の情報処理装置３１から通知された同意IDの正当性についての確認を第２の情報処理装置３２に依頼する。

そして、その正当性が第２の情報処理装置３２の確認部５４ｂによって確認されたときに、第３のメッセージ制御部６１が第１の情報処理装置３１に属性情報３８を通知する。なお、同意IDの正当性が確認されないときは、第３のメッセージ制御部６１は第１の情報処理装置３１に属性情報３８を通知しない。

また、判断部６４ｂは、ユーザが未同意の属性情報３８を提供するのを防ぐために、第２の情報処理装置３２から属性情報３８の提供についてユーザの同意が得られとの情報が通知されたとき、その属性情報３８が第１の情報処理装置３１が要求するものと同一かを判断する。

次に、本実施形態に係る情報提供システムの動作について説明する。

図９及び図１０は、本実施形態に係る情報提供システムの動作の一例を示すシーケンス図である。

以下では、ユーザが端末３４を操作することにより、第１の情報処理装置３１が募集している翻訳アルバイトに応募する場合を例にして説明する。この場合、ユーザの英語力を確認するために、第１の情報処理装置３１は第３の情報処理装置３３から属性情報３８として語学スコア記録証を要求する。

更に、第１の情報処理装置３１は、ユーザと連絡を取るために、第２の情報処理装置３２に対して属性情報３７としてメールアドレスを要求するものとする。また、第３の情報処理装置３３は、語学スコア記録証がユーザ本人のものであるかを確認するために、第２の情報処理装置３２に対して氏名と住所とを要求するものとする。

なお、図９及び図１０において、実線で示す処理はOpenID Connectに即した処理を示し、一点鎖線で示す処理はOAuth 2.0に即した処理を示す。また、点線で示す処理は、これらのプロトコルで規定されていない処理を示す。

以下、図９及び図１０に示す処理をステップ番号に沿って説明する。

(S50)まず、第１の情報処理装置３１が募集している翻訳アルバイトに応募するために、ユーザが端末３４を操作することにより、webブラウザ３５から第１の情報処理装置３１にサービス要求を通知する。

(S51)そのサービス要求を受けて、第１の情報処理装置３１の第１のメッセージ制御部４１が、第２の情報処理装置３２に対して承認依頼７０を通知する。

承認依頼７０は、属性情報３７（メールアドレス）と属性情報３８（語学スコア記録証）とを第１の情報処理装置３１が取得してよいとの承認を第２の情報処理装置３２に求めるHTTPリクエストであり、端末３４から第２の情報処理装置３２にリダイレクトされる。

なお、この承認依頼７０には、第３の情報処理装置３３が属性情報３７（氏名、住所）を取得してよいとの承認を第２の情報処理装置３２に求める依頼も含まれる。

また、この例ではHTTPヘッダにFEDパラメータを設け、そのFEDパラメータに連携IDの値を指定する。

連携IDは、前述のように第１〜第３の情報処理装置３１〜３３のうちどの情報処理装置が連携してユーザにサービスを提供するのかを示すIDであって、連携管理部４２によりHTTPヘッダに付加される。

連携に関与する第１〜第３の情報処理装置３１〜３３とFEDパラメータの値との対応関係は特に限定されない。

例えば、第１〜第３の情報処理装置３１〜３３の全てが連携する場合には、FED=001とし得る。

一方、第３の情報処理装置３３が連携に関与せずに、第１の情報処理装置３１と第２の情報処理装置３２のみが連携する場合には、HTTPヘッダにFEDパラメータを含めない。

本例では、第１〜第３の情報処理装置３１〜３３の全てが連携するため、FED=001とする。

なお、各属性情報３７、３８のうちのどの情報を各情報処理装置３１〜３３のうちのどの情報処理装置に提供するかは、各情報処理装置３１〜３３の間で予め取り決められている。

よって、FEDパラメータにより連携に関与する情報処理装置が分かれば、各属性情報３７、３８のうちのどの情報を各情報処理装置３１〜３３のうちのどの情報処理装置に提供するかを判断できる。したがって、提供を求める属性情報を承認依頼７０のscopeパラメータに指定しなくても、第２の情報処理装置３２は、FEDパラメータを参照することでどの属性情報をどの情報処理装置に提供すべきかを判断できる。

例えば、FED=001の場合には、属性情報３７（メールアドレス）と属性情報３８（語学スコア記録証）とを第１の情報処理装置３１に提供し、かつ、第３の情報処理装置３３に属性情報３７（氏名、住所）を提供することを予め決めておく。これにより、第２の情報処理装置３２は、FED=001のときの各属性情報３７、５８の提供先がどの情報処理装置であるかを判断できる。

(S52)第２の情報処理装置３２の制御部５４が、承認依頼７０に付加されたFEDパラメータの値を同意テーブル５５（図８参照）の「連携ID」に格納する。

これと共に、制御部５４は、同意テーブル５５の「連携元」に「第１の情報処理装置３１」を格納する。前述のように、「連携元」は、承認依頼７０を要求してきた要求元の情報処理装置であって、その承認依頼７０の送信元URLから制御部５４が判断する。

(S53)第２の情報処理装置３２の認証部５２は、ユーザが第２の情報処理装置３２と第３の情報処理装置３３の各々を利用する権限があるかを確認するために、端末３４に対して認証要求７１を通知する。

また、第２の情報処理装置３２の第２のメッセージ制御部５１が端末３４との間でユーザセッションを確立し、そのユーザセッションに対応したcookieを生成する。そして、第２のメッセージ制御部５１が認証要求７１にそのcookieを付加し、端末３４のwebブラウザ３５がそのcookieを受け取る。

なお、webブラウザ３５は、以降のステップで第２の情報処理装置３２にアクセスするときは、このcookieを第２の情報処理装置３２の第２のメッセージ制御部５１に渡す。

(S54)ユーザは、第２の情報処理装置３２にログインするための認証ID（A_ID）とパスワード（PW）を端末３４のwebブラウザ３５に入力する。そして、その認証IDとパスワード（PW）とが、認証情報７２としてwebブラウザ３５から第２の情報処理装置３２に通知される。

なお、この例ではシングルサイオンを採用するため、第３の情報処理装置３３にログインするための認証は、第２の情報処理装置３２にログインするための認証が成功すれば不要である。

その後、認証部５２は、その認証情報７２が第２の記憶部５３に予め登録されている認証情報３９と等しいかどうかを確認し、両者が等しい場合に認証が成功したと判断する。

(S55)ステップS54の認証が成功した場合、第２の情報処理装置３２の第２のメッセージ制御部５１が端末３４に同意要求７３を通知する。

その同意要求７３は、第１〜第３の情報処理装置３１〜３３のいずれかに属性情報３７や属性情報３８を提供してよいとの同意をユーザに求める要求である。

ここで、提供すべき属性情報３７、３８と、提供先の第１〜第３の情報処理装置３１〜３３とは、ステップS52で同意テーブル５５に格納されている連携IDに基づいて第２のメッセージ制御部５１が判断する。

例えば、連携IDのFEDパラメータが001の場合は、第２のメッセージ制御部５１が第１〜第３の情報処理装置３１〜３３の全てがサービスに関与すると判断する。そして、第２のメッセージ制御部５１が、その同意要求７３に、属性情報３７（メールアドレス）と属性情報３８（語学スコア記録証）とを第１の情報処理装置３１に提供してよいとの同意を含める。また、第２のメッセージ制御部５１は、その同意要求７３に、第３の情報処理装置３３に属性情報３７（氏名、住所）を提供してもよいとの同意も含める。

(S56)ユーザは、属性情報３７（メールアドレス、氏名、住所）と属性情報３８（語学スコア記録証）の提供に同意するときは、端末３４を操作して第２の情報処理装置３２に同意７４を通知する。

このように複数の属性情報３７、３８の提供についての同意を一度で済ますことで、ユーザの負担軽減を実現することができる。

なお、同意７４には、ステップS53で第２の情報処理装置３２から渡されたcookieがwebブラウザ３５により付加される。

(S57)上記の同意７４を受けて、第２の情報処理装置３２の生成部５４ｂが同意IDを生成する。その同意IDは、制御部５４によって同意テーブル５５の属性「同意ID」に格納される。ここでは、例えば同意ID = ID00xyzとする。

更に、制御部５４が、同意７４に含まれるcookieに対応したユーザセッションを同意テーブル５５の「ユーザセッション」に格納する。

(S58)第２の情報処理装置３２の第２のメッセージ制御部５１は、ステップS51の承認依頼７０に対する応答を第１の情報処理装置３１に通知するために、第１の情報処理装置３１に許可応答７５を返す。

その許可応答７５はHTTPレスポンスであって、端末３４により第１の情報処理装置３１にリダイレクトされる。このリダイレクトの際、そのHTTPヘッダには、ステップS53で第２の情報処理装置３２から端末３４に渡されたcookieが、端末３４により付加される。

更に、そのHTTPヘッダには、ステップS57で生成した同意IDが第２のメッセージ制御部５１により付加される。

図１１は、許可応答７５の一例を示す図である。

この例では、HTTPヘッダにconsentIDパラメータ７５ａを設け、そのconsentIDパラメータに同意IDのID00xyzを指定する。

また、このHTTPレスポンスには許可コード７５ｂも付加される。許可コード７５ｂは、第２の情報処理装置３２が生成した記号列であって、HTTPレスポンスのLocationヘッダに指定される。その許可コードは、第２の情報処理装置３２から属性情報３７（メールアドレス）の提供を受けるためのアクセストークンと後で交換される。

再び図９を参照する。

(S59)第１の情報処理装置３１の連携管理部４２は、許可応答７５に付加されている同意IDを第１の記憶部４４に格納する。

(S60)第１の情報処理装置３１の第１のメッセージ制御部４１は、第２の情報処理装置３２に対してアクセストークン要求を通知する。

アクセストークン要求は、第２の情報処理装置３２から属性情報３７（メールアドレス）を得る際に必要となるアクセストークンを要求するHTTPリクエストであって、そのHTTPヘッダのgrant_typeパラメータには前述の許可コードが指定される。

(S61)第２の情報処理装置３２の第２のメッセージ制御部５１は、そのアクセストークン要求に含まれている許可コードの正当性を検証する。

そして、検証に成功した場合には、第２のメッセージ制御部５１が第１の情報処理装置３１にアクセストークン応答を返す。

アクセストークン応答は、許可コードをアクセストークンに交換し、そのアクセストークンを第１の情報処理装置３１に通知するためのHTTPレスポンスである。アクセストークンは、第２のメッセージ制御部５１が生成した記号列であって、HTTPヘッダのaccess_tokenパラメータに指定される。

また、アクセストークンは、第２の情報処理装置３２が所有する複数の属性情報３７のうち、提供を許可する属性情報３７を特定するIDとしての機能も有する。

なお、有効期限が切れたアクセストークンの代替となるリフレッシュトークンもアクセストークン応答に含めてもよい。これについては、後述の各アクセストークン応答でも同様である。

(S62)第１の情報処理装置３１の第１のメッセージ制御部４１は、第２の情報処理装置３２にアクセストークンを渡すことにより、第２の情報処理装置３２にデータ要求を通知する。この場合に要求するデータは、ユーザの属性情報３７（メールアドレス）である。

また、このデータ要求はHTTPリクエストであって、そのHTTPヘッダのaccess_tokenパラメータに上記のアクセストークンが指定される。

(S63)第２の情報処理装置３２の第２のメッセージ制御部５１は、第１の情報処理装置３１から渡されたアクセストークンと、自身がステップS61で発行したアクセストークンとの同一性を確認する。

そして、その同一性が確認できた場合には、第２のメッセージ制御部５１は、アクセストークンに対応した属性情報３７（メールアドレス）を特定する。その後、その属性情報３７（メールアドレス）をデータ応答に乗せて第２の情報処理装置３２に通知する。

ここまでのステップにより、第１の情報処理装置３１が属性情報３７（メールアドレス）を取得できたことになる。

次に、第１の情報処理装置３１は、以下のようにして第３の情報処理装置３３が保有する属性情報３８（語学スコア記録証）の取得を試みる。

(S64)まず、第１の情報処理装置３１の第１のメッセージ制御部４１が、第３の情報処理装置３３に対して許可要求７６を通知する。

この許可要求７６は、第３の情報処理装置３３が保有している属性情報３８（語学スコア記録証）の提供についての許可を要求するHTTPリクエストであり、端末３４によって第３の情報処理装置３３にリダイレクトされる。

また、第３の情報処理装置３３が保有している複数の属性情報３８のうち、第１の情報処理装置３１が要求する情報が語学スコア記録証であることを通知するために、HTTPヘッダのscopeパラメータにはその語学スコア記録証が指定される。

更に、第１の情報処理装置３１の連携管理部４２は、記憶部４４に格納しておいた同意IDをそのHTTPヘッダのconsentIDパラメータに指定する。これにより、同意IDが第３の情報処理装置３３に通知されることになる。

(S65)第３の情報処理装置３３の管理部６４は、同意IDを第３の記憶部６２に格納する。

(S66)管理部６４の依頼部６４ａは、第１の情報処理装置３１から通知された同意IDの正当性を確認するために、第３のメッセージ制御部６１を介して第２の情報処理装置３２に対して確認依頼７７を通知する。

その確認依頼７７は、属性情報３７（氏名、住所）の取得についての許可を第２の情報処理装置３２に要求する許可要求も兼ねたHTTPリクエストであり、そのHTTPヘッダのscopeパラメータには氏名と住所が指定される。

また、第２の情報処理装置３２に同意IDを通知するために、HTTPヘッダのconsentIDパラメータには、第３の記憶部６２に格納した同意IDが同意管理部６４により指定される。

なお、その確認依頼７７は端末３４から第２の情報処理装置３２にリダイレクトされる。そのリダイレクトの際、端末３４のwebブラウザ３５によって確認依頼７７にcookieが付加される。

(S67)第２の情報処理装置３２の確認部５４ｂは、確認依頼７７に付加された同意IDの正当性を確認する。同意IDの正当性とは、その同意IDがステップS57で生成されたものであることを言う。

同意IDの正当性を確認するために、確認部５４ｂは、確認依頼７７の同意ID（ID00xyz）が同意テーブル５５に存在するか否かを確認する。そして、同意IDが同意テーブル５５に存在した場合、同意IDの正当性が確認されたことになる。

ここで、このように同意IDの正当性が確認された場合は、属性情報３８の提供についてのユーザの同意が既に済んでいることになる。

一方、同意IDの正当性が確認されない場合は、ユーザが同意していない状態で第１の情報処理装置３１が第３の情報処理装置３３の属性情報３８を不正に取得しようとしていることになる。よって、この場合には第２の情報処理装置３２から第１の情報処理装置３１にエラーメッセージを通知し、これ以降の処理は行わない。これにより、ユーザが同意していない状態で第１の情報処理装置３１が第３の情報処理装置３３の属性情報３８を不正に取得するのを防止することができる。

また、確認部５４ｂが、確認依頼７７に付加されたcookieに基づいてユーザセッションを特定し、そのユーザセッションが同意テーブル５５に存在するかどうかを確認してもよい。

その確認の結果、ユーザセッションが同意テーブル５５に存在しないと判断された場合には、ステップS56で同意７４を通知したのとは別の端末３４が使用されており、ユーザが入れ替わっている可能性がある。よって、この場合にも第２の情報処理装置３２から第１の情報処理装置３１にエラーメッセージを通知し、これ以降の処理は行わない。これにより、ユーザのなりすましを防止することができる。

(S68)ステップS67で同意IDの正当性が確認された場合には、第２の情報処理装置３２の第２のメッセージ制御部５１が第３の情報処理装置３３に応答通知７８を通知する。

その応答通知７８は、確認依頼７７に応答するためのHTTPレスポンスであり、端末３４から第３の情報処理装置３３にリダイレクトされる。

そして、その応答通知７８には、ユーザが属性情報３８（語学スコア記録証）の提供に同意した旨の情報が含まれる。

ここで、第３の情報処理装置３３の判断部６４ｂは、応答通知７８においてユーザが提出に同意したとされる属性情報３８と、許可要求７６において第３の情報処理装置３３が提供を求める属性情報３８とが同一かどうかを判断する。

これらの属性情報３８が同一でない場合には、ユーザが提供に同意していない属性情報３８（例えば看護師免許）を第３の情報処理装置３３が不正に取得しようとしていることになる。

よって、この場合には第３の情報処理装置３３のメッセージ制御部６１から第１の情報処理装置３１にエラーメッセージを通知し、これ以降の処理は行わない。これにより、ユーザが提供に同意していない属性情報３８が第１の情報処理装置３１に不正に取得されるのを防止することができる。

なお、この応答通知７８は、第２の情報処理装置３２の属性情報３７（氏名、住所）を第３の情報処理装置３３に提供するのを許可する許可通知も兼ねる。そのため、応答通知７８のHTTPヘッダには、属性情報３７（氏名、住所）の提供を受けるために必要なアクセストークンと後で交換される許可コードが付加される。

(S69)第３の情報処理装置３３の第３のメッセージ制御部６１は、第２の情報処理装置３２に対してアクセストークン要求を通知する。このアクセストークン要求は、第２の情報処理装置３２から属性情報３７（氏名、住所）を得る際に必要となるアクセストークンを要求するHTTPリクエストである。

更に、そのHTTPリクエストのヘッダには、アクセストークンに引き換えられるステップS68の許可コードが付加される。

(S70)第２の情報処理装置３２の第２のメッセージ制御部５１は、そのアクセストークン要求に含まれている許可コードの正当性を検証し、検証に成功した場合には第３の情報処理装置３３にアクセストークン応答を返す。

アクセストークン応答は、許可コードと引き換えにアクセストークンを第３の情報処理装置３３に通知するためのHTTPレスポンスである。そして、第２のメッセージ制御部５１が生成した記号列で表されるアクセストークンが、HTTPヘッダのaccess_tokenパラメータに指定される。

このアクセストークンは、第２の情報処理装置３２が所有する複数の属性情報３７のうち、提供を許可する属性情報３７を特定するためのIDとしての機能も兼ねる。

(S71)第３の情報処理装置３３の第３のメッセージ制御部６１は、アクセストークンを第２の情報処理装置３２に渡すことにより、第２の情報処理装置３２にデータ要求を通知する。この場合に要求するデータは、前述のようにユーザの属性情報３７（氏名、住所）である。

(S72)第２の情報処理装置３２の第２のメッセージ制御部５１は、第３の情報処理装置３３から渡されたアクセストークンと、自身がステップS70で発行したアクセストークンとの同一性を確認する。

そして、その同一性が確認できた場合には、第２のメッセージ制御部５１は、第３の情報処理装置３３から通知されたアクセストークンに対応する属性情報３７（氏名、住所）を特定する。その後、第２のメッセージ制御部５１は、その属性情報３７（氏名、住所）をデータ応答に乗せて第３の情報処理装置３３に通知する。

ここまでのステップにより、第３の情報処理装置３３が属性情報３７（氏名、住所）を取得できたことになる。

(S73)第３の情報処理装置３３の第３のメッセージ制御部６１は、ステップS68における応答通知７８を受けて、第１の情報処理装置３１に許可応答７９を通知する。

この許可応答７９は、属性情報３８（語学スコア記録証）の取得を第３の情報処理装置３３に許可するHTTPレスポンスであり、端末３４により第１の情報処理装置３１にリダイレクトされる。

このHTTPレスポンスのLocationヘッダには、第３のメッセージ制御部６１が生成した記号列が許可コードとして格納される。この許可コードは、属性情報３８（語学スコア記録証）の提供を受けるためのアクセストークンと後で交換される。

なお、ステップS68で判断部６４ｂが許可要求７６と応答通知７８のそれぞれに含まれる属性情報３８が同一でないと判断した場合には、前述のようにユーザが提供に同意していない属性情報３８を第１の情報処理装置３１が不正に取得しようとしていることになる。よって、この場合には、第３のメッセージ制御部６１はこの許可応答７９を第１の情報処理装置３１に通知しない。

これにより、ユーザが提供に同意していない属性情報３８（例えば看護師免許）が第１の情報処理装置３１に不正に取得されるのを防止できる。

(S74)第１の情報処理装置３１の第１のメッセージ制御部４１は、第３の情報処理装置３３に対してアクセストークン要求を通知する。このアクセストークン要求は、第３の情報処理装置３３から属性情報３８（語学スコア記録証）を得る際に必要となるアクセストークンを要求するHTTPリクエストである。

また、そのアクセストークンのHTTPヘッダのgrant_typeフィールドには、ステップS73で第３の情報処理装置３３が発行した許可コードが格納される。

(S75)第３の情報処理装置３３の第３のメッセージ制御部６１は、そのアクセストークンに含まれている許可コードの正当性を検証し、検証に成功した場合には第１の情報処理装置３１にアクセストークン応答を返す。

アクセストークン応答は、許可コードと引き換えにアクセストークンを第１の情報処理装置３１に通知するためのHTTPレスポンスである。そして、第３の情報処理装置３３が生成した記号列で表されるアクセストークンが、そのHTTPレスポンスのaccess_tokenパラメータに指定される。

アクセストークンは、第３の情報処理装置３３が所有する複数の属性情報３８のうち、提供を許可する属性情報３８（語学スコア記録証）を特定するIDとしての機能も有する。

(S76)第１の情報処理装置３１の第１のメッセージ制御部４１は、アクセストークンを第３の情報処理装置３３に渡すことにより、第３の情報処理装置３３にデータ要求を通知する。この場合に要求するデータはユーザの属性情報３８（語学スコア記録証）である。

(S77)第３の情報処理装置３３の第３のメッセージ制御部６１は、第１の情報処理装置３１が提示したアクセストークンと、自身がステップS75で発行したアクセストークンとの同一性を確認する。

そして、その同一性が確認できた場合には、第３のメッセージ制御部６１は、アクセストークンに対応した属性情報３８（語学スコア記録証）を特定する。その後、その属性情報３８（語学スコア記録証）をデータ応答に乗せて第１の情報処理装置３１に通知する。

ここまでのステップにより、第１の情報処理装置３１が属性情報３８（語学スコア記録証）を取得できたことになる。

なお、前述のようにステップS67で同意IDの正当性が確認されない場合にはステップS67以降の処理を行わないため、本ステップS77において第３のメッセージ制御部６１が第１の情報処理装置３１に属性情報３８（語学スコア記録証）を通知することはない。

これにより、ユーザが同意していない状態で第１の情報処理装置３１が第３の情報処理装置３３の属性情報３８を不正に取得するのを防止できる。

同様に、ステップS68において、許可要求７６と応答通知７８の各々に含まれる属性情報３８が一致しない場合にも、本ステップS77において第３のメッセージ制御部６１が第１の情報処理装置３１に属性情報３８（語学スコア記録証）を通知することはない。

その結果、ユーザが提供に同意していない属性情報３８が第１の情報処理装置３１に取得されるのを防止することが可能となる。

(S78)第１の情報処理装置３１のサービスアプリケーション３１は、ユーザの属性情報３８（語学スコア記録証）に基づいて、翻訳アルバイトの採用の可否を決定する。そして、その結果をサービス応答として端末３４に通知する。

以上により、本実施形態に係る情報提供システムにおける基本処理を終了する。

この情報提供システムによれば、ステップS55で連携IDに基づいて全ての情報処理装置３１〜３３がサービスに関与すると第２のメッセージ制御部５１が判断したとき、同意要求７３に複数の属性情報３７、３８の提供についての同意を含める。

そのため、ユーザは、ステップS56において複数の属性情報３７、３８の提供についての同意を一度で済ますことができる。これにより、それぞれの属性情報３７、３８ごとにユーザに同意を求める場合と比較して、同意に伴うユーザの負担軽減を実現することができる。

更に、ステップS67において確認依頼７７に付加された同意IDの正当性を確認することで、属性情報３８の提供についてユーザが同意済みかどうかを確認できる。そのため、ユーザが同意していない状態で第１の情報処理装置３１が第３の情報処理装置３３の属性情報３８を不正に取得するのを防止することができる。

しかも、このようにシステムにOpenID ConnectとOAuth 2.0の二つのプロトコルが混在していても、上記のようにメッセージに同意IDを付加してユーザの同意を管理することで、各プロトコルを一つのプロトコルのように扱うこともできる。

次に、図９と図１０の各処理を実現するための第２の情報処理装置３２の処理内容について説明する。

図１２〜図１５は、第２の情報処理装置３２の処理内容について示すフローチャートである。

なお、第２の情報処理装置３２の処理内容は、第２の情報処理装置３２が受信するメッセージの種類によって異なる。そこで、以下ではメッセージごとに処理内容を説明する。

＜承認依頼７０を受信したとき＞
図１２は、承認依頼７０（図９参照）を受信したときの第２の情報処理装置３２の処理内容を示すフローチャートである。

この場合は、連携IDのFEDパラメータの値により処理が異なる。

まず、FEDパラメータがない場合について説明する。

前述のように、FEDパラメータがない場合は、第１の情報処理装置３１と第２の情報処理装置３２のみが連携してサービスを提供し、第３の情報処理装置３３はサービスに関与しない。

この場合は、ステップS100において、ステップS53、S54のユーザ認証が済んでいるか否かを認証部５２が判断する。

そして、認証済みである（YES）と判断された場合にはステップS103に移る。そのステップS103では、第２の情報処理装置３２が保有する属性情報３７のみの提供についてユーザに同意を求める同意要求を第２のメッセージ制御部５１が端末３４に通知する。

一方、ステップS100において認証済みではない（NO）と判断された場合にはステップS53に移る。

そのステップS53では、図９を参照して説明したように、端末３４に対して認証要求７１を通知する。

次に、FED=001の場合について説明する。

前述のように、FED=001の場合は、第１〜第３の情報処理装置３１〜３３の全てが連携してユーザにサービスを提供する。

この場合は、ステップS101において、ステップS55のユーザ認証が済んでいるか否かを認証部５２が判断する。

ここで、認証済みではない（NO）と判断された場合にはステップS52に移る。

図９を参照して説明したように、ステップS52においては、制御部５４が、承認依頼７０に付加されたFEDパラメータの値を同意テーブル５５（図８参照）の「連携ID」に格納する。これと共に、制御部５４は、同意テーブル５５の「連携元」に「第１の情報処理装置３１」を格納する。

次に、図９で説明したステップS53に移り、端末３４に対して認証要求７１を通知する。

一方、ステップS101において認証済みである（YES）と判断された場合にはステップS102に移る。

この場合は、第２の情報処理装置３２が承認依頼７０を受信した時点で、既にステップS55のユーザ認証が済んでいることになる。しかし、図９のシーケンスでは、第２の情報処理装置３２が承認依頼７０を受信した後にステップS55が行われており、これらが逆の順序で起こることは想定されない。よって、この場合には想定外の事態が生じたとして、制御部５４が第１の情報処理装置３１にエラーメッセージを送信する。

＜確認依頼７７を受信したとき＞
図１３は、確認依頼７７（図１０参照）を受信したときの第２の情報処理装置３２の処理内容を示すフローチャートである。

まず、ステップS110において、ステップS53、S54のユーザ認証が済んでいるか否かを認証部５２が判断する。

そして、認証済みである（YES）と判断された場合にはステップS67に移る。

図９を参照して説明したように、ステップS67においては、確認依頼７７に含まれる同意IDが同意テーブル５５に存在するか否かが制御部５４の確認部５４ｂで確認される。

そして、同意IDが同意テーブル５５に存在する（YES）と判断された場合にはステップS111に移る。

ステップS111においては、確認部５４ｂが、同意テーブル５５の「状態チェックフラグ」を「1」にセットする。

次に、ステップS68に移る。ステップS68では、図１０を参照して説明したように、第２の情報処理装置３２の第２のメッセージ制御部５１が第３の情報処理装置３３に応答通知７８を返す。

一方、ステップS110において認証済みではない（NO）と判断された場合にはステップS112に移る。

この場合は、第２の情報処理装置３２に確認依頼７７が通知された時点で、ステップS54のユーザ認証が行われていないことになる。しかし、図９〜図１０のシーケンスによれば、ステップS53、S54のユーザ認証が行われた後に第２の情報処理装置３２に確認依頼７７が通知される。よって、想定外の事態が生じたとして、この場合には制御部５４が第１の情報処理装置３１にエラーメッセージを送信する。

＜認証情報７２を受信したとき＞
図１４は、認証情報７２（図９参照）を受信したときの第２の情報処理装置３２の処理内容を示すフローチャートである。

まず、ステップS121において、ステップS54（図９参照）の認証が成功したかどうかを認証部５２が判断する。そして、認証が成功したとき（YES）は、ステップS122に移る。

そのステップS122においては、制御部５４が、承認依頼７０に付加されているFEDパラメータの値が「001」であるか否かを判断する。

そして、「001」である（YES）と判断された場合にはステップS55に移る。

前述のように、FED=001のときは、第１〜第３の情報処理装置３１〜３３の全てが連携することにより、属性情報３７（メールアドレス、氏名、住所）と属性情報３８（語学スコア記録証）とが提供先に提供されることが予め決められている。

よって、ステップS55では、図９を参照して説明したように、これらの属性情報３７、３８の提供についてユーザに同意を求める同意要求７３を端末３４に通知する。

一方、ステップS121において、認証が失敗したとき（NO）は、ステップS123に移り、認証が失敗した旨の通知を端末３４に通知する。

また、ステップS122においてFEDパラメータの値が「001」ではない（NO）と判断された場合にはステップS124に移る。

本例では、FEDパラメータの値が「001」であるか、FEDパラメータ自体が存在しないかの二通りしか想定していないため、FEDパラメータの値が「001」ではない場合にはFEDパラメータが存在しないということになる。

また、FEDパラメータが存在しない場合には、前述のように第１の情報処理装置３１と第２の情報処理装置３２のみが連携する。よって、この場合には、第２の情報処理装置３２が保有する属性情報３７のみの提供についてユーザに同意を求める同意要求を端末３４に通知する。

＜同意７４を受信したとき＞
図１５は、同意７４（図９参照）を受信したときの第２の情報処理装置３２の処理内容を示すフローチャートである。

まず、ステップS130において、ユーザが属性情報３７、３８の提供に同意したか否かを同意７４に基づいて制御部５４が判断する。

ここで、同意した（YES）と判断した場合にはステップS131に移る。

そのステップS131においては、第２の情報処理装置３２の確認部５４ｂが、同意テーブル５５におけるFEDパラメータの値が「001」であるか否かを判断する。

そして、「001」である（YES）と判断された場合にはステップS57に移る。

図９を参照して説明したように、ステップS57においては、制御部５４が同意IDを生成し、その同意IDを同意テーブル５５に格納する。

また、これと共に、同意７４に含まれるcookieに対応したユーザセッションを第２のメッセージ制御部５１が同意テーブル５５に格納する。

次に、ステップS58に移り、第２のメッセージ制御部５１が許可応答７５に同意IDを付加し、その許可応答７５を端末３４に通知する。

一方、ステップS130においてユーザが同意していない（NO）と判断した場合にはステップS135に移る。

この場合は、ユーザが属性情報３７（氏名、住所、メールアドレス）と属性情報３８（語学スコア記録証）の提出に同意していないことになる。よって、この場合には、第２のメッセージ制御部５１が第１の情報処理装置３１にエラーメッセージを送信する。

また、ステップS131においてFEDパラメータの値が「001」ではない（NO）と判断された場合にはステップS134に移る。

この場合にはFEDパラメータが存在しないことになるため、前述のように第１の情報処理装置３１と第２の情報処理装置３２のみが連携し、第３の情報処理装置３３はサービスに関与しない。

よって、この場合には、第１の情報処理装置３１が第３の情報処理装置３３に属性情報３８を要求することは想定されないので、第１の情報処理装置３１が属性情報３８を不正に取得するのを防止するための同意IDは不要である。そのため、第２の情報処理装置３２の第２のメッセージ制御部５１は、許可応答７５に同意IDを付加せずに、当該許可応答７５を第１の情報処理装置３１に通知する。

（第２実施形態）
第１実施形態では、図１１に示したように、OAuthやOpenID Connect等の既存のプロトコルでは規定されていないconsentIDをメッセージに追加することにより、ユーザが同意していない属性情報３８が不正に取得されるのを防止した。

これに対し、本実施形態では、既存のプロトコルでは規定されてないパラメータを追加せずに、属性情報３８が不正に取得されるのを防止する。

図１６及び図１７は、本実施形態に係る情報提供システムの動作の一例を示すシーケンス図である。

なお、図１６及び図１７において、第１実施形態で説明したのと同じ要素とステップには第１実施形態におけるのと同じ符号を付し、以下ではその説明を簡略化する。

また、第１実施形態と同様に、図１６及び図１７において実線で示す処理はOpenID Connectに即した処理を示し、一点鎖線で示す処理はOAuth 2.0に即した処理を示す。また、点線で示す処理は、これらのプロトコルで規定されていない処理を示す。

本実施形態では、以下のようにしてOAuth 2.0で規定されているstateパラメータを同意IDとして使用する。

以下、図１６及び図１７に示す処理をステップ番号に沿って説明する。

(S50)まず、ユーザが端末３４を操作することにより、第１の情報処理装置３１にサービス要求を通知する。

(S51)そのサービス要求を受けて、第１の情報処理装置３１の第１のメッセージ制御部４１が第２の情報処理装置３２に対して承認依頼７０を通知する。

本実施形態では、第１のメッセージ制御部４１がその承認依頼７０のHTTPヘッダにstateパラメータを設定する。stateパラメータは、後述のCSRF(Cross Site Request Forgery)攻撃への対策としてOAuth 2.0で規定されている記号列である。

stateパラメータの生成方法は特に限定されない。以下では、第１実施形態で説明した連携IDと同意IDとを結合した記号列をstateパラメータとする。

例えばstate=RID00xyzとした場合、先頭の「R」が連携IDであり、後続の「ID00xyz」が同意IDである。

なお、連携IDの「R」は、第１〜第３の情報処理装置３１〜３３の全てが連携することを示す。第３の情報処理装置３３が連携に関与せずに、第１の情報処理装置３１と第２の情報処理装置３２のみが連携する場合には、先頭の「R」を省くものとする。

(S90)第２の情報処理装置３２の制御部５４が、承認依頼７０に付加されたstateパラメータを同意テーブル５５に格納する。

図１８は、本実施形態に係る同意テーブル５５の一例を示す図である。

本実施形態では、同意テーブル５５には「state」、「ユーザセッション」、「連携元」、及び「状態チェックフラグ」の各属性が設定される。

これらのうち、属性「state」にstateパラメータの値（RID00xyz）が格納される。

なお、第１実施形態と同様に、本ステップでは制御部５４が同意テーブル５５の「連携元」に「第１の情報処理装置３１」を格納する。

(S53)第２の情報処理装置３２は、端末３４に対して認証要求７１を通知する。なお、その認証要求７１には、端末３４のユーザセッションに対応したcookieが第２のメッセージ制御部５１により付加される。

(S54)ユーザの操作のもとで、webブラウザ３５は、第２の情報処理装置３２にログインするための認証IDとパスワードとを認証情報７２として第２の情報処理装置３２に通知する。

(S55)ステップS54の認証が成功した場合、第２の情報処理装置３２の第２のメッセージ制御部５１が端末３４に同意要求を通知する。

その同意要求は、属性情報３７（メールアドレス）と属性情報３８（語学スコア記録証）とを第１の情報処理装置３１に提供してよいとの同意と、第３の情報処理装置３３に属性情報３７（氏名、住所）を提供してもよいとの同意をユーザに要求するものである。

(S56)ユーザは、属性情報３７（メールアドレス、氏名、住所）と属性情報３８（語学スコア記録証）の提供に同意するときは、端末３４を操作して第２の情報処理装置３２に同意７４を通知する。

第１実施形態で説明したように、このように複数の属性情報３７、３８の提供についての同意を一度で済ますことで、ユーザの負担軽減を実現することができる。

なお、その同意７４には、ステップS53で第２の情報処理装置３２から渡されたcookieがwebブラウザ３５により付加される。

(S91)第２の情報処理装置３２の第２のメッセージ制御部５１が、同意７４に含まれるcookieに対応したユーザセッションを同意テーブル５５の属性「ユーザセッション」に格納する。

(S58)第２の情報処理装置３２の第２のメッセージ制御部５１は、端末３４に許可応答７５をHTTPレスポンスで返す。

その許可応答７５のHTTPヘッダには、同意テーブル５５にあるstateパラメータと、ステップS91で生成したcookieとが第２のメッセージ制御部５１により付加される。

前述のように、stateパラメータは、連携IDと同意IDとが連結された記号列である。よって、本ステップにより、その記号列の一部が同意IDとして第１の情報処理装置３１に通知されることになる。

更に、第２のメッセージ制御部５１は、アクセストークンと後で交換される許可コードをHTTPヘッダに付加する。

(S92)第１の情報処理装置３１の連携管理部４２は、許可応答７５に付加されているstateパラメータを第１の記憶部４４に格納する。

(S60)第１の情報処理装置３１の第１のメッセージ制御部４１は、第２の情報処理装置３２に対してアクセストークン要求を通知する。そのアクセストークン要求のHTTPヘッダには、第１のメッセージ制御部４１により前述の許可コードが格納される。

(S61)第２の情報処理装置３２の第２のメッセージ制御部５１は、そのアクセストークン要求に含まれている許可コードの正当性を検証する。

そして、検証に成功した場合には、第２のメッセージ制御部５１が第１の情報処理装置３１にアクセストークン応答を返し、第２の情報処理装置３２にアクセストークンを渡す。

(S62)第１の情報処理装置３１の第１のメッセージ制御部４１は、第２の情報処理装置３２にアクセストークンを渡すことにより、第２の情報処理装置３２にデータ要求を通知する。この場合に要求するデータは、ユーザの属性情報３７（メールアドレス）である。

(S63)第２の情報処理装置３２の第２のメッセージ制御部５１は、第１の情報処理装置３１から渡されたアクセストークンと、自身がステップS61で発行したアクセストークンとの同一性を確認する。

その同一性が確認できた場合には、第２の情報処理装置３２は、属性情報３７（メールアドレス）をデータ応答に乗せて第２の情報処理装置３２に通知する。

ここまでのステップにより、第１の情報処理装置３１が属性情報３７（メールアドレス）を取得できたことになる。

次に、第１の情報処理装置３１は、以下のようにして第３の情報処理装置３３が保有する属性情報３８（語学スコア記録証）の取得を試みる。

(S64)まず、第１の情報処理装置３１の第１のメッセージ制御部４１が、第３の情報処理装置３３に対して許可要求７６を通知する。

この許可要求は、第３の情報処理装置３３が保有している属性情報３８（語学スコア記録証）の提供を要求するHTTPリクエストであって、scopeパラメータにはその語学スコア記録証が指定される。

更に、第１の情報処理装置３１の第１のメッセージ制御部４１は、記憶部４４に格納しておいたstateパラメータをHTTPヘッダに付加することにより、そのstateパラメータを第３の情報処理装置３３に渡す。

前述のようにstateパラメータの一部は同意IDとして機能するため、本ステップにより同意IDが第３の情報処理装置３３に通知されることになる。

(S93)第３の情報処理装置３３の管理部６４が、その同意IDを含むstateパラメータを第３の記憶部６２に格納する。

(S66)管理部６４の依頼部６４ａは、第１の情報処理装置３１から通知された同意IDの正当性を確認するために、第３のメッセージ制御部６１を介して第２の情報処理装置３２に対して確認依頼７７を通知する。

その確認依頼７７は、属性情報３７（氏名、住所）の取得についての許可を第２の情報処理装置３２に要求する許可要求も兼ねたHTTPリクエストであり、そのHTTPヘッダのscopeパラメータには氏名と住所が指定される。

また、第２の情報処理装置３２に同意IDを通知するために、HTTPヘッダのconsentIDパラメータには、第３の記憶部６２に格納したstateパラメータが同意管理部６４により指定される。

なお、その確認依頼７７は端末３４から第２の情報処理装置３２にリダイレクトされる。そのリダイレクトの際、端末３４のwebブラウザ３５によって確認依頼７７にcookieが付加される。

(S67)第２の情報処理装置３２の確認部５４ｂは、確認依頼７７に付加された同意IDの正当性を確認するために、その同意IDを一部に含むsateパラメータのチェックを行う。

本実施形態における同意IDの正当性とは、確認依頼７７で通知されたstateパラメータが、ステップS50において第１の情報処理装置３１が自ら生成して依頼承認７０に付加したstateパラメータと同一であることをいう。

同意IDの正当性を確認するために、確認部５４ｂは、確認依頼７７のstateパラメータ（RID00xyz）が同意テーブル５５に存在するか否かを確認する。そして、stateパラメータが同意テーブル５５に存在した場合、同意IDの正当性が確認されたことになる。

ここで、このように同意IDの正当性が確認された場合は、ユーザの同意７４を受けて第２の情報処理装置３２が通知する許可応答７５に含まれるstateパラメータと、確認依頼７７に含まれるstateパラメータとが同一ということになる。

よって、この場合にはユーザの同意を属性情報３８の提供についてのユーザの同意が既に済んでいることになる。

一方、同意IDの正当性が確認されない場合は、ユーザが同意していない状態で第１の情報処理装置３１が第３の情報処理装置３３の属性情報３８を不正に取得しようとしていることになる。したがって、この場合には第２の情報処理装置３２から第１の情報処理装置３１にエラーメッセージを通知し、これ以降の処理は行わない。これにより、ユーザが同意していない状態で第１の情報処理装置３１が第３の情報処理装置３３の属性情報３８を不正に取得するのを防止することができる。

また、第１実施形態と同様に、確認部５４ｂが、確認依頼７７に付加されたcookieに基づいてユーザセッションを特定し、そのユーザセッションが同意テーブル５５に存在するかどうかを確認してもよい。

ステップS67で同意IDの正当性が確認された場合には、第１実施形態と同様にしてステップS68〜S78を行う。これにより、ステップS77において第１の情報処理装置３１が属性情報３８（語学スコア記録証）を取得することができる。

以上説明した本実施形態によれば、OAuthやOpenID Connect等の既存のプロトコルで規定されているstateパラメータを承認依頼７０に付加することにより、既存のプロトコルの範疇で第１の情報処理装置３１の不正を検出できる。

しかも、そのstateパラメータとして同意IDと連携IDとを結合した記号列を使用することで、連携ID用のパラメータをHTTPヘッダに追加することなしに、各情報処理装置３１〜３３のどれが連携するのかを確認できる。

更に、そのstateパラメータは、以下のようにCSRF攻撃への対策ともなる。

図１９は、CSRF攻撃について説明するためのシーケンス図である。

なお、図１９において、図１６及び図１７で説明したのと同じ要素とステップにはこれらの図におけるのと同じ符号を付し、以下ではその説明を省略する。

図１９の例では端末３４が二台あり、ユーザセッションがUser001sで表される端末が攻撃者により操作され、ユーザセッションがUser002sで表される端末が被害者により操作されているものとする。

このとき、攻撃者の端末３４は、OAuth 2.0の仕様に反して、ステップS140において許可要求７６を第３の情報処理装置３３にリダイレクトさせずに、何らかの手法で被害者の端末３４に許可要求７６を渡す。

そして、被害者の端末３４は、OAuth 2.0の仕様に従って、ステップS141において許可要求７６を本来のリダイレクト先である第３の情報処理装置３３にリダイレクトする。

その結果、これ以降のステップでは、被害者の端末３４と各情報処理装置３１〜３３との間でユーザセッションが確立されることになる。これにより、例えばアクセストークンとユーザセッションとが対応付けられている場合、各情報処理装置３１〜３３に攻撃者が保有しているアカウントに対するアクセストークンが、被害者のユーザセッションと対応付くことになる。これにより、攻撃者のアカウントに被害者のリソースを登録させる等の不正を行うことができる。

本実施形態では、これを防止するために、図１８に示すように、同意テーブル５５においてstateパラメータとユーザセッションとを対応させる。

これにより、ステップS67で確認依頼７７のstateパラメータが同意テーブル５５に存在しても、ユーザセッションが同意テーブル５５にない場合にはCSRF攻撃を受けている可能性があると判断でき、CSRF攻撃に対するシステムの堅牢性が増す。

（ハードウェア構成）
上記した第１実施形態と第２実施形態で説明した各種の処理は、予め用意されたプログラムをコンピュータで実行することで実現できる。そこで、以下では、上記の各実施形態と同様の機能を有するプログラムを実行するコンピュータの一例について説明する。

図２０は、第１及び第２実施形態に係る情報提供プログラムを実行するコンピュータのハードウェア構成図である。

以下では、第１〜第３の情報処理装置３１〜３３と端末３４のそれぞれにコンピュータ１００を用意する。

コンピュータ１００の台数は特に限定されない。例えば、複数のコンピュータ１００が第１の情報処理装置３１の処理を実行してもよい。これについては、第２及び第３の情報処理装置３２、３３についても同様である。

そのコンピュータ１００は、各種演算処理を実行するCPU(Central Processing Unit)１０１と、データ入力を受け付ける入力装置１０２と、モニタ１０３とを有する。

また、コンピュータ１００は、記憶媒体１１０からプログラムを読み取る媒体読取装置１０４と、各種装置と接続するためのインタフェース装置１０５と、他の装置と有線または無線により接続するための通信装置１０６とを有する。

更に、コンピュータ１００は、各種情報を一時記憶するRAM(Random Access Memory)１０７と、ハードディスク装置１０８とを有する。なお、各装置１０１〜１０８は、バス１０９に接続される。

上記のハードディスク装置１０８には、第１〜第３の情報処理装置３１〜３３と端末３４のそれぞれの機能を実現するための情報提供プログラムが記憶される。

例えば、第１の情報処理装置３１用のハードディスク装置１０８には、第１のメッセージ制御部４１、第１の連携管理部４２、サービスアプリケーション４３、及び第１の記憶部４４の各部の機能を有する情報提供プログラムが記憶される。

また、第２の情報処理装置３２用のハードディスク装置１０８には、第２のメッセージ制御部５１、認証部５２、第２の記憶部５３、制御部５４、及び同意テーブル５５の各部の機能を有する情報提供プログラムが記憶される。

更に、第３の情報処理装置３３用のハードディスク装置１０８には、第３のメッセージ制御部６１、第３の記憶部６２、サービスアプリケーション６３、及び管理部６４の各部の機能を有する情報提供プログラムが記憶される。

そして、端末３４用のハードディスク装置１０８には、webブラウザ３５としての機能を有する情報提供プログラムが記憶される。

一方、入力装置１０２は、例えばユーザからパスワードの入力を受け付けたり、コンピュータ１００の管理者から管理情報の入力を受け付けたりする。モニタ１０３は、例えば認証のためのパスワード入力画面を表示したり、コンピュータ１００の管理者がメンテナンス等を行う場合に各種情報を表示したりする。

インタフェース装置１０５には、例えば不図示の印刷装置等が接続される。通信装置１０６は、ネットワーク３５に接続され、第１〜第３の情報処理装置３１〜３３と端末３４のそれぞれの間の通信を行う。

また、CPU１０１は、ハードディスク装置１０８に記憶された前述の情報提供プログラムを読み出して、RAM１０７に展開して実行する。これにより、CPU１０１やRAM１０７等のハードウェア資源と情報提供プログラムとが協働して図７に示した第１〜第３の情報処理装置３３と端末３４の各機能が実現される。

また、上記の情報提供プログラムをコンピュータ１００が読み取り可能な記録媒体１１０に記憶させておき、コンピュータ１００に記録媒体１１０の情報提供プログラムを読み取らせるようにしてもよい。

そのような記録媒体１１０としては、例えばCD-ROM(Compact Disc - Read Only Memory)、DVD(Digital Versatile Disc)、及びUSB(Universal Serial Bus)メモリ等の可搬型記憶媒体がある。また、フラッシュメモリ等の半導体メモリやハードディスクドライブを記憶媒体１１０として使用してもよい。これらの記憶媒体１１０は、物理的な形態を持たない搬送波のような一時的な媒体ではない。

更に、公衆回線、インターネット、及びLAN等に接続された装置にこの情報処理プログラムを記憶させておき、コンピュータ１００がこれらから情報処理プログラムを読み出して実行するようにしてもよい。

以上説明した各実施形態に関し、更に以下の付記を開示する。

（付記１） 第１の情報処理装置、第２の情報処理装置、及び第３の情報処理装置を備えた情報提供システムであって、
前記第１の情報処理装置は、
前記第３の情報処理装置が保有するユーザの属性情報を取得することについての承認を求める承認依頼を前記第２の情報処理装置に通知し、前記属性情報の取得について前記ユーザの同意が得られたことを示す同意識別子が前記第２の情報処理装置から通知されたときに、前記同意識別子を前記第３の情報処理装置に通知する第１の通知部、
を有し、
前記第２の情報処理装置は、
前記第３の情報処理装置からの依頼を受けて、前記第３の情報処理装置から通知された前記同意識別子の正当性を確認する確認部と、
前記承認依頼を受けたときに前記属性情報を前記第１の情報処理装置に提供することについての前記同意を前記ユーザに要求し、前記同意が得られたときに前記同意識別子を前記第１の情報処理装置に通知する第２の通知部と、
を有し、
前記第３の情報処理装置は、
前記属性情報を記憶した記憶部と、
通知された前記同意識別子の前記正当性についての確認を前記第２の情報処理装置に依頼する依頼部と、
前記確認部によって前記正当性が確認されたときに前記第１の情報処理装置に前記属性情報を通知し、前記正当性が確認されないときには前記第１の情報処理装置に前記属性情報を通知しない第３の通知部、
を有する、
ことを特徴とする情報提供システム。

（付記２） 前記第１の通知部は、前記第２の情報処理装置から前記同意識別子が通知された場合に、前記属性情報の提供についての許可を求める要求を前記第３の情報処理装置に通知し、
前記第２の通知部は、前記確認部により前記正当性が確認されたときに、前記属性情報の提供についてユーザが同意した旨の情報を前記第３の情報処理装置に通知し、
前記第３の情報処理装置は、前記第２の通知部から通知された前記情報における前記属性情報と、前記第１の通知部から要求された前記属性情報とが一致しているかを判断する判断部を有し、
前記第３の通知部は、前記判断部によって前記属性情報が一致していないと判断されたときには、前記第１の情報処理装置に前記属性情報を通知しないことを特徴とする付記１に記載の情報提供システム。

（付記３） 前記ユーザが操作する端末を更に有し、
前記確認部は、前記端末と前記第２の情報処理装置との間で確立されたユーザセッションと、前記同意をした前記ユーザのユーザセッションとの同一性を確認し、
前記第２の通知部は、前記ユーザセッションの前記同一性がないときには、前記ユーザが提供に同意した前記属性情報を前記第３の情報処理装置に通知しないことを特徴とする付記１又は付記２に記載の情報提供システム。

（付記４） 前記第２の情報処理装置は、前記第３の情報処理装置が保有するのとは別の属性情報を記憶した別の記憶部を有し、
前記同意には、前記別の属性情報を前記第３の情報処理装置に提供することについての同意が含まれることを特徴とする付記１乃至付記３のいずれかに記載の情報提供システム。

（付記５） 前記第１の情報処理装置は、前記第１乃至第３の情報処理装置のうちのどれが連携して前記ユーザにサービスを提供するのかを特定する連携識別子を前記承認依頼に付加する連携管理部を有し、
前記第２の通知部は、前記連携識別子に基づいて第１乃至第３の情報処理装置の全てが連携することが確認できた場合に、前記別の記憶部に記憶された前記別の属性情報を前記第３の情報処理装置に提供することについての同意を前記同意に含めることを特徴とする付記４に記載の情報提供システム。

（付記６） 前記第１の通知部は前記承認依頼に記号列を付加し、
前記第２の通知部は、前記記号列の一部を前記同意識別子として前記第１の情報処理装置に通知することを特徴とする付記１に記載の情報提供システム。

（付記７） 前記記号列のうち、前記同意識別子を除いた残りの部分は、前記第１乃至第３の情報処理装置のうちのどれが連携して前記ユーザにサービスを提供するのかを特定する連携識別子であることを特徴とする付記６に記載の情報提供システム。

（付記８） 前記第２の情報処理装置は、前記承認依頼を受けて前記ユーザの認証を行う認証部を有することを特徴とする付記１に記載の情報提供システム。

（付記９） 前記確認部は、前記第２の通知部が前記第１の情報処理装置に通知した前記同意識別子を記憶したテーブルを用い、前記テーブルの前記同意識別子と、前記第３の情報処理装置から通知された前記同意識別子とが同一であるかどうかを確認することにより、前記正当性の確認を行うことを特徴とする付記１に記載の情報提供システム。

（付記１０） 第１の情報処理装置が、ユーザの属性情報を取得することについての承認を第２の情報処理装置に依頼し、
前記依頼を受けた前記第２の情報処理装置が、前記属性情報を前記第１の情報処理装置に提供することについての同意を前記ユーザに要求し、
前記ユーザの同意が得られたとき、前記第２の情報処理装置が、前記同意が得られたことを示す同意識別子を前記第１の情報処理装置に通知し、
前記同意識別子の通知を受けた前記第１の情報処理装置が、前記属性情報を保有する第３の情報処理装置に前記同意識別子を通知し、
前記同意識別子の通知を受けた前記第３の情報処理装置が、前記第２の情報処理装置に対し、通知された前記同意識別子の正当性の確認を依頼し、
前記正当性が確認されたときに前記第３の情報処理装置が前記第１の情報処理装置に前記属性情報を通知し、前記正当性が確認されないときには前記第３の情報処理装置が前記第１の情報処理装置に前記属性情報を通知しないことを特徴とする情報提供方法。

（付記１１） 前記同意識別子の通知を受けた前記第１の情報処理装置が、前記第３の情報処理装置に対し、前記属性情報の提供について許可を求める要求を通知し、
前記正当性が確認された場合、前記第２の情報処理装置が、前記属性情報の提供についてユーザが同意した旨の情報を第３の情報処理装置に通知し、
前記第３の情報処理装置は、前記第２の情報処理装置から通知された前記情報における前記属性情報と、前記第１の情報処理装置から要求された前記属性情報とが一致していない場合には、前記第１の情報処理装置に前記属性情報を通知しないことを特徴とする付記１０に記載の情報提供方法。

（付記１２） 第１の情報処理装置が、ユーザの属性情報を取得することについての承認を第２の情報処理装置に依頼する処理と、
前記依頼を受けた前記第２の情報処理装置が、前記属性情報を前記第１の情報処理装置に提供することについての同意を前記ユーザに要求する処理と、
前記ユーザの同意が得られたとき、前記第２の情報処理装置が、前記同意が得られたことを示す同意識別子を前記第１の情報処理装置に通知する処理と、
前記同意識別子の通知を受けた前記第１の情報処理装置が、前記属性情報を保有する第３の情報処理装置に前記同意識別子を通知する処理と、
前記同意識別子の通知を受けた前記第３の情報処理装置が、前記第２の情報処理装置に対し、通知された前記同意識別子の正当性の確認を依頼する処理と、
前記正当性が確認されたときに前記第３の情報処理装置が前記第１の情報処理装置に前記属性情報を通知し、前記正当性が確認されないときには前記第３の情報処理装置が前記第１の情報処理装置に前記属性情報を通知しない処理と、
をコンピュータに実行させる情報提供プログラム。

１〜３…第１〜第３の情報処理装置、２ａ、３ａ…記憶部、４…端末、７、８…属性情報、９…サービス要求、１０…システム、３１〜３３…第１〜第３の情報処理装置、３４…端末、３５…webブラウザ、３６…ネットワーク、３７、３８…属性情報、３９…認証情報、４１…第１のメッセージ制御部、４２…連携管理部、４３…サービスアプリケーション、４４…第１の記憶部、５１…第２のメッセージ制御部、５２…認証部、５３…第２の記憶部、５４…制御部、５４ａ…生成部、５４ｂ…確認部、５５…同意テーブル、６１…第３のメッセージ制御部、６２…第３の記憶部、６３…サービスアプリケーション、６４…管理部、６４ａ…依頼部、６４ｂ…判断部。

Claims (6)

1. 第１の情報処理装置、第２の情報処理装置、及び第３の情報処理装置を備えた情報提供
   システムであって、
   前記第１の情報処理装置は、
   前記第３の情報処理装置が保有するユーザの属性情報を取得することについての承認
   を求める承認依頼を前記第２の情報処理装置に通知し、前記属性情報の取得について前記
   ユーザの同意が得られたことを示す同意識別子が前記第２の情報処理装置から通知されたときに、前記同意識別子を前記第３の情報処理装置に通知する第１の通知部、を有し、
   前記第２の情報処理装置は、
   前記第３の情報処理装置からの依頼を受けて、前記第３の情報処理装置から通知された前記同意識別子の正当性を確認する確認部と、
   前記承認依頼を受けたときに前記属性情報を前記第１の情報処理装置に提供することに
   ついての前記同意を前記ユーザに要求し、前記同意が得られたときに前記同意識別子を前
   記第１の情報処理装置に通知する第２の通知部と、を有し、
   前記第３の情報処理装置は、
   複数の前記属性情報を記憶した記憶部と、
   通知された前記同意識別子の前記正当性についての確認を前記第２の情報処理装置に依
   頼する依頼部と、
   前記確認部によって前記正当性が確認されたときに、複数の前記属性情報のうち、提供を許可する属性情報を特定するアクセストークンを前記第１の情報処理装置へ通知し、前記第１の情報処理装置からの前記アクセストークンの通知を受けて、前記アクセストークンによって特定される属性情報を前記第１の情報処理装置に通知し、前記正当性が確認されないときには前記第１の情報処理装置に前記属性情報を通知しない第３の通知部、を有する、ことを特徴とする情報提供システム。
2. 前記第１の通知部は、
   前記第２の情報処理装置から前記同意識別子が通知された場合に、前記属性情報の提供についての許可を求める要求を前記第３の情報処理装置に通知し、
   前記第２の通知部は、
   前記確認部により前記正当性が確認されたときに、前記属性情報の提供についてユーザが同意した旨の情報を前記第３の情報処理装置に通知し、
   前記第３の情報処理装置は、
   前記第２の通知部から通知された前記情報における前記属性情報と、前記第１の通知部から要求された前記属性情報とが一致しているかを判断する判断部を有し、
   前記第３の通知部は、
   前記判断部によって前記属性情報が一致していないと判断されたときには、前記第１の情報処理装置に前記属性情報を通知しないことを特徴とする請求項１に記載の情報提供システム。
3. 前記ユーザが操作する端末を更に有し、
   前記確認部は、
   前記端末と前記第２の情報処理装置との間で確立されたユーザセッションと、前記同意をした前記ユーザのユーザセッションとの同一性を確認し、
   前記第２の通知部は、
   前記ユーザセッションの前記同一性がないときには、前記ユーザが提供に同意した前記属性情報を前記第３の情報処理装置に通知しないことを特徴とする請求項１又は２に記載の情報提供システム。
4. 前記第１の通知部は前記承認依頼に記号列を付加し、
   前記第２の通知部は、前記記号列の一部を前記同意識別子として前記第１の情報処理装
   置に通知することを特徴とする請求項１乃至３のいずれか１項に記載の情報提供システム。
5. 第１の情報処理装置が、ユーザの属性情報を取得することについての承認を第２の情報処理装置に依頼し、
   前記依頼を受けた前記第２の情報処理装置が、前記属性情報を前記第１の情報処理装置に提供することについての同意を前記ユーザに要求し、
   前記ユーザの同意が得られたとき、前記第２の情報処理装置が、前記同意が得られたことを示す同意識別子を前記第１の情報処理装置に通知し、
   前記同意識別子の通知を受けた前記第１の情報処理装置が、複数の前記属性情報を保有する第３の情報処理装置に前記同意識別子を通知し、
   前記同意識別子の通知を受けた前記第３の情報処理装置が、前記第２の情報処理装置に対し、通知された前記同意識別子の正当性の確認を依頼し、
   前記正当性が確認されたときに前記第３の情報処理装置が前記第１の情報処理装置に、複数の前記属性情報のうち、提供を許可する属性情報を特定するアクセストークンを前記第１の情報処理装置へ通知し、前記第１の情報処理装置からの前記アクセストークンの通知を受けて、前記アクセストークンによって特定される属性情報を通知し、前記正当性が確認されないときには前記第３の情報処理装置が前記第１の情報処理装置に前記属性情報を通知しないことを特徴とする情報提供方法。
6. 第１の情報処理装置が、ユーザの属性情報を取得することについての承認を第２の情報処理装置に依頼する処理と、
   前記依頼を受けた前記第２の情報処理装置が、前記属性情報を前記第１の情報処理装置に提供することについての同意を前記ユーザに要求する処理と、
   前記ユーザの同意が得られたとき、前記第２の情報処理装置が、前記同意が得られたことを示す同意識別子を前記第１の情報処理装置に通知する処理と、
   前記同意識別子の通知を受けた前記第１の情報処理装置が、複数の前記属性情報を保有する第３の情報処理装置に前記同意識別子を通知する処理と、
   前記同意識別子の通知を受けた前記第３の情報処理装置が、前記第２の情報処理装置に対し、通知された前記同意識別子の正当性の確認を依頼する処理と、
   前記正当性が確認されたときに前記第３の情報処理装置が前記第１の情報処理装置に、複数の前記属性情報のうち、提供を許可する属性情報を特定するアクセストークンを前記第１の情報処理装置へ通知し、前記第１の情報処理装置からの前記アクセストークンの通知を受けて、前記アクセストークンによって特定される前記属性情報を通知し、前記正当性が確認されないときには前記第３の情報処理装置が前記第１の情報処理装置に前記属性情報を通知しない処理と、
   をコンピュータに実行させる情報提供プログラム。

Images