http://openid.dbcls.jp/user/nakao が http://openid.dbcls.jp/user/nakao/ でもOpenIDとして利用できるのは不具合でしょうか？

[mn]

例として、 http://openid.dbcls.jp/user/nakao が、

•  http://openid.dbcls.jp/user/nakao/ でページが表示できて
•  http://openid.dbcls.jp/user/nakao/ をRPでOpenIDとして利用すると、そのままリダイレクトできて

います。

これらは（仕様として）意図している動作でしたら、仕様変更を考えたいです。 （仕様として）意図していない場合はバグなのかどうか判断したいです。

URLのノーマライズでは、パスの末尾/の有無は区別されるべきものですので、現状では、openid.dbcls.jp でアカウントをつくると、二つのOpenIDが発行されていると同等な状態になっているといえます。 さらに、 https:// スキーマもあるので、４個のOpenIDが発行されているともいえます。

OpenIDサーバの上記動作について報告します。

ご報告いただいている動作はOpenIDの仕様となっております。 しかし、運用方法としましてはサーバ側の仕様を変更するというよりは、
クライアント側で表示の制御をかけていただく方がより自然です。

OpenIDの仕様としてクライアント側の入力にて 以下のような正規化を行う処理を期待しています。  http://openid.net/specs/openid-authentication-2_0.html#normalization_example

通常では利用側(クライアント)は、末尾に '/' を付与して処理を行います。

そのためOpenIDサーバ側では直接入力された場合は、4つすべてのIDを通してます。
これはmyopenid.comなど他のプロバイダも同様です。

httpsに関しましても、クライアント側がよりセキュアな方が望ましいのであれば、
httpsを利用するということで対応いただけると思います。 ただしURLの表示はhttpで表示されていますので、その場合も同様に混乱の元になると予想されます。

なかおの理解では、現在のOpenID.dbcls.jpの動作はOpenIDの仕様通りではありません。 ホスト名の末尾の/の有無は区別されませんが、パスの末尾/は区別されるものです。 これは間違っていますか？

 http://openid.net/specs/openid-authentication-2_0.html#normalization_example からの抜粋ですが、

example.com	http://example.com/	URL	A URI with a missing scheme is normalized to a http URI
http://example.com	http://example.com/	URL	An empty path component is normalized to a slash
https://example.com/	https://example.com/	URL	https URIs remain https URIs

１カラム目がユーザの入力、２カラム目がIDですが、ホスト名なので末尾/が補完されたうえでIDとなっています。myopenid.com の動作はこちらになります。

http://example.com/user	http://example.com/user	URL	No trailing slash is added to non-empty path components
http://example.com/user/	http://example.com/user/	URL	Trailing slashes are preserved on non-empty path components

パスの末尾/の場合は補完しません。したがって、パスの末尾/の有無によって ID がことなります。openid.dbcls.jpではこちらの動作がOpenIDの仕様通りだと思いますが、そうなっていません。はてなOpenIDではこちらの動作になっています。

ここでいま問題にしていることを整理します。

1. パスの末尾/の処理がOpenIDの仕様を満たしていないのでユーザあたり二つのIDが存在する。
2. https と http の両方が存在しているので、ユーザあたり合計４個のIDが存在する。
3. openid.dbcls.jp ではユーザには  http://openid.dbcls.jp/user/nakao のようにユーザのIDを表示している。
4. ユーザに明示的に教えていないIDでも利用できる状態になっている。
5. ユーザに明示的に教えていないIDでもリダイレクトしている。
6. ユーザがRPで既存のアカウントにdbcls openid をひもづけるときに不適切なOpenIDを入力した場合にログインできる場合とできない場合が生じる。

関連して、

3. XRDSエントリーポイントが https なので、RP が openssl ライブラリをもつことが必要である。

これらは技術的な問題とOPとしての振る舞いの問題のふたつが絡んでいます。

あたらしい技術なので、ベストプラクティス的なものが不足していて、大変なぶぶんだとは認識しています。 そのうえで、山際さんには、「予想されます」というような意見は期待していません。 もう少し実際に利用して運用してていくときの判断に有効な回答を期待しています。

説明の際に不十分な点があり申し訳ありませんでした。

中尾様にあげていただいた下記問題について回答いたします。

1. パスの末尾/の処理がOpenIDの仕様を満たしていないのでユーザあたり二つのIDが存在する。

OpenIDの仕様上はOpenID の仕様上はサーバ側が提供する
URL (http(s)://openid.dbcls.jp/user/xxxx(/) に制限はありません。

これはクライアント側とサーバ側で複数のIDをどう扱うかについての 検討をしていないため、こういった問題が発生しています。
そのため中尾様のご指摘されているパスの末尾の/についても、 クライアントとサーバで取り扱い方法について検討すべき項目となります。

2. https と http の両方が存在しているので、ユーザあたり合計４個のIDが存在する。
3. openid.dbcls.jp ではユーザには  http://openid.dbcls.jp/user/nakao のようにユーザのIDを表示している。
4. ユーザに明示的に教えていないIDでも利用できる状態になっている。
5. ユーザに明示的に教えていないIDでもリダイレクトしている。
6. ユーザがRPで既存のアカウントにdbcls openid をひもづけるときに不適切なOpenIDを入力した場合にログインできる場合とできない場合が生じる。

弊社西村に確認しましたところ、 開発時はOreFiLしかクライアント側の実装がなかったため特に上記問題に対するポリシーについて決定しておらず、 順に各クライアントが実装されていく過程で、疎通の確認をしましょうという取り決めをお客様との間で確認していると聞いております。
※実際OreFiLは4つのIDすべてを同一ユーザとして認識します。

3．XRDSエントリーポイントが https なので、RP が openssl ライブラリをもつことが必要である。

OpenID認証では、盗聴について脆弱である可能性があります。
そのため、経路を暗号化(https でのアクセス)する事が推奨されていましたので、 本システムではその方法を採用し、エントリーポイントを https とする事で実現しています。

弊社としましては現状で考えられる対応方法として、以下の対応をご提案いたします。

1．各クライアント側で入力された URL についてチェックする

例として、内部的には必ず末尾の "/" を除去して処理を行う。
メリットとしては、openid.dbcls.jp 以外の OpenID サーバとの連携が容易になります。
逆にデメリットとしては、各クライアント毎に同様の処理が必要となります。

2. サーバ側で特定の URL 以外をエラーとする

例として、 http://openid.dbcls.jp/user/xxxx 以外は 404 のエラーを返す。
メリットとしては、各クライアントでの実装が容易になります。
デメリットとしては、末尾に/を付与するサービスもありますので、 OpenID サーバが dbcls 以外のクライアントとの疎通が困難になる可能性があります。

これは弊社が提供しております保守サービスとの兼ね合いになりますが、 対応方法2の場合につきましては追加開発となる認識でおります。
恐れ入りますが、この場合の対応については別途契約とした上で 調整させていただければと思います。

この度判明したのですが、

※実際OReFiLは4つのIDすべてを同一ユーザとして認識します。

これは違うように見受けられます。というのも、orefil データベースで下記の通りとなっており、yayamamo について4つのIDが別々に認識されています。

mysql> select * from users where openid_url like "%yayamamo%";
+----+----------------------------------------+-----------+---------------------+---------------------+
| id | openid_url                             | name      | created_at          | updated_at          |
+----+----------------------------------------+-----------+---------------------+---------------------+
|  6 | http://openid.dbcls.jp/user/yayamamo   | [no name] | 2008-02-21 15:10:48 | 2008-06-16 19:17:26 | 
| 17 | https://openid.dbcls.jp/user/yayamamo  | [no name] | 2008-06-04 19:45:11 | 2008-06-16 19:17:08 | 
| 23 | https://openid.dbcls.jp/user/yayamamo/ | [no name] | 2008-06-16 19:26:59 | 2008-07-09 14:38:53 | 
| 24 | http://openid.dbcls.jp/user/yayamamo/  | [no name] | 2008-06-16 19:27:14 | 2008-06-16 19:27:14 | 
+----+----------------------------------------+-----------+---------------------+---------------------+
4 rows in set (0.00 sec)

ご指摘の箇所ですが、OpenIDとOreFiLの関係について誤解を生む表記となっておりました。
【誤】※実際OReFiLは4つのIDすべてを同一ユーザとして認識します。
【正】※OpenIDサーバはOreFiLからの4つのIDすべてを同一ユーザとして認識します。

ご指摘いただいたOreFiLデータベースのusersテーブルに登録されているのは、OreFiLにて入力されたIDに対してサインインが許可された際に、登録されていなければレコードを作成し、その後は最新のサインイン時間を管理するテーブルになります。

OreFiL側からすると4つのIDがある事と変わらないですが、OpenIDサーバで認証されるユーザは1つのIDということになります。
そのため、OreFiL側では対象のユーザは1つですが、現状ではそれぞれ記法の異なる4つのIDについてレコードを作成しています。
ちなみにOpenID側のusersテーブルでは、OreFiLのユーザIDについては4つのIDすべてを1つのIDとして管理しております。

#193の追加開発により解決とする

チケット番号に誤りがありました。失礼いたしました。 #192の追加開発により解決とする