JanRain の PHP 版 について
LDU05653
現在、携帯電話の個体識別番号の様な用途で OpenID の Claimed Identifier を使おうと画策し、RP? の構築中です
システム全体を PHP で組んでいますので PHP で、しかも OpenID2.0 (XRI) に対応したく JanRain の php-
openid-2.0.1 の Consumer の部分を利用しようと考えています
そこで教えていただきたいのですが、認証の完了後、帰ってくる identity_url に 余計な URL (PHP で言うところの
fragment でしょうか？) がついてしまい、扱いに困っています
具体的には、Yahoo! JAPAN で認証を受けた場合ですが、
https://me.yahoo.co.jp/a/XXXXX39TV.B8ViMk8P4qVtiTEciC (一部伏せ字) に続
き、#33967 が identity_url について帰ってきてしまいます
本来は
https://me.yahoo.co.jp/a/XXXXX39TV.B8ViMk8P4qVtiTEciC と帰ってくることを期待しています
が
https://me.yahoo.co.jp/a/XXXXX39TV.B8ViMk8P4qVtiTEciC#33967 となってしま
い、identity_url を事前に登録した物と一致させることが出来ません
これは、配布元の デモ も同じようです
http://openidenabled.com/php-openid/trunk/examples/consumer/
他のサーバで認証を受ける際は問題ないようです
OpenID.ne.jp 、haneta、などで試してみましたが、登録した際に通知された identity_url が帰ってきます
ソースの中を見ましたが、getArg() 辺りか？などと考えましたが、具体的な修正ポイントもうまく見つけられずに困っています
（OpenID Enabled の他の言語のデモは問題ないように見えますので、PHP 版特有の問題に思っています..）
英語が不得意で仕様もうまく拾えないのですが、“#” に続いた URL はこっちで（自営の部分）で削除してしまって良いのか？などとも考えていま
す
他に、投稿するような場所も思いつきませんでしたので、こちらに投稿させていただきました
アドバイスなどをいただけると助かります
以上、よろしくお願いいたします
Takatsugu Shigeta
> 英語が不得意で仕様もうまく拾えないのですが、"#" に続いた URL はこっちで（自営の部分）で削除してしまって良いのか？などとも考えていま
> す
私は JanRain の PHP に触れたことはないのですが、
この話はOpenID 2.0 になって各所で話があがっていますが、
7.2 normalization の 3 が参考になります。
<snip>
さもなければ、入力はHTTP URLとして扱われるべきです;
もしそれが"http"か"https"スキームを含まないなら、そのIdentifierは文字列"http://"を先頭につけられなければなりません。もしそのURLがfragmentパートを含むなら、それはfragmentを区切る文字"#"と合わせて取り除かれなかればなりません。更なる情報の為にSection
11.5.2 (HTTP and HTTPS URL Identifiers)を読んでください。
</snip>
http://lab.koshigoe.jp/en2ja/openid-authentication-2_0.html#normalization
2008/4/2 LDU05653 <LDU0...@gmail.com>:
--
Takatsugu Shigeta
LDU05653
内容によれば、自営の部分でフラグメントの部分を取ってしまう細工をしておいた方がよい様に思います
スキームの補完などの正規化も併せて考えなければいかもしれません
早速、作業しようと思います
有り難うございました
Nat Sakimura
Tatsuhiko Miyagawa
> この話はOpenID 2.0 になって各所で話があがっていますが、
> 7.2 normalization の 3 が参考になります。
このnormalization はユーザが Identity URLを入力して OpenID
の認証セッションを開始するときに行うもので、認証がおわってもどってきた identity_url に対して実行するものではないですね。
--
Tatsuhiko Miyagawa
Tatsuhiko Miyagawa
> 本来は
> https://me.yahoo.co.jp/a/XXXXX39TV.B8ViMk8P4qVtiTEciC と帰ってくることを期待していますが
> https://me.yahoo.co.jp/a/XXXXX39TV.B8ViMk8P4qVtiTEciC#33967 となってしま
> い、identity_url を事前に登録した物と一致させることが出来ません
「事前に登録した物」が何を意味しているのかわからないのですが、User-Supplied Identifier のことだとすれば、ユーザが
yahoo.co.jp のように Directed Identity を入力した場合、そもそも Claimed Identity
とは異なる値になるのが当然なのでは。
--
Tatsuhiko Miyagawa
LDU05653
----
OpenID設定情報
あなたのOpenIDは、 https://me.yahoo.co.jp/a/XXXXX39TV.B8ViMk8P4qVtiTEciC で
す。
----
となります
エンドユーザには、この 「あなたのOpenID」を登録するように促してみようと思った訳です
OpenID.ne.jp も、アカウントを確認すると
----
http://LDU05653.openid.ne.jp
----
となります
そこで、これをエンドユーザさんに自分で登録してもらおうかと考えました
そこで、Yahoo! JAPAN の認証後に フラグメントがついてきてしまい、これをエンドユーザは確認することが出来ません（よね？）
で、どうしよう！となった訳です
先にも記しましたが、システムを PHP で構築している都合上、JanRain の PHP 版のフレームワークで構築することが最適解なのですが、
フラグメントがついてきます
JanRain の他の 言語の Ruby や Perl のデモを実行すると フラグメントは付いてこないようです
そこで、このPHP 版だけに付いてくる（と思われる）フラグメントの扱いに付いてどうするのが最適なのか？と言うことを考えていました
LDU05653
> JanRain の他の 言語の Ruby や Perl のデモを実行すると フラグメントは付いてこないようです
Nat Sakimura
Perl では無く、Python でした
> JanRain の他の 言語の Ruby や Perl のデモを実行すると フラグメントは付いてこないようです
LDU05653
「OpenID認可モジュール」から 「OpenIDログイン」(openid_consumer.html) へ
そして、tyr_auth -> finish_auth を順に実行し、この間にClaimed Identifier を入手しておく
その後に、register.php へ処理を移行し新規登録や Claimed Identifier の追加登録処理を行う
register.php 内で getDisplayIdentifier() から $displayId を、$response-
>identity_url で、 $cid を取り出し、これをデータベースに登録する処理を行う
（OP に一度問い合わせて、その上で処理をする）
おおざっぱですが、こういう流れでしょうか？
現在、構築中のシステムは、簡易にログインさせることが目的で、ユーザの登録作業は委任された管理者が行います
ですので、http://www.sakimura.org/ の link.php へ流れる処理方法を参考にさせていただこうと思います
（すでに登録されているユーザ情報にユーザが自分で OpenID を登録する感じの処理の流れです）
（（将来的に、OP も自営したいと考えていますが..））
ですが、やはり気になるのが「あなたのOpenID:https://me.yahoo.co.jp/a/
XXXXX39TV.B8ViMk8P4qVtiTEciC#33967」です
Yahoo! JAPAN の表示する
-----
「Yahoo! JAPANの方針
あなたのOpenIDは、www.sakimura.orgへ送信されます。
https://me.yahoo.co.jp/a/XXXXX39TV.B8ViMk8P4qVtiTEciC
Yahoo! JAPAN ID、パスワード、あるいは個人情報は、www.sakimura.orgへ送信されません。Yahoo! JAPANは、
お客様からwww.sakimura.orgに提供された情報を管理いたしません。」
と微妙に異なってしまう所に引っかかってしまいますが...
Fumiaki Yoshimatsu
参考：
http://wiki.openid.net/OpenIDChanges#Explicitly_allow_fragments_on_OpenID_identifiers
The OpenID provider can send a URL with a fragment as the claimed
identifier. The full URL (with the fragment) is the user's identifier,
so relying parties store the URL with the fragment.
とこれはみなさんおっしゃっているとおり、フラグメント付きで格納しておけと。
ですが、
The URL without the fragment should be used when the URL has to be displayed.
表示するときはとっちゃえばいいじゃんと。
吉松
LDU05653
> とこれはみなさんおっしゃっているとおり、フラグメント付きで格納しておけと。
>
> ですが、
>
> The URL without the fragment should be used when the URL has to be displayed.
>
> 表示するときはとっちゃえばいいじゃんと。
>
先に崎村 さんが記された
> フラグメントを切り捨てたものは、あくまでユーザ提供識別子であって、Claimed Identifier として取り扱うことはできません。
>
> この仕様は、OPがあるURLを別のユーザに割り当てたような場合(URL Recycling）に対応するために2.0で追加されたセキュリティ機能です。
には事由が判りませんよね？
そう言う事象が起きないように OP が担保している訳では無いと言うことですよね？
「別のユーザに割り当てたような場合」が想定されていると言うことは、容易に想像できます
たとえば鈴木一郎さんが所有を主張した http://www.example.com/suzuki/ を手放し、鈴木次郎さんが同じ OP で同じ
ようにID を取得した場合、フラグメントなどの情報がないと一意であることを担保できません
# URL Recycling は多分そう言うことですよね？
## 鈴木一郎さんと鈴木次郎さんが同じサービスを利用する場合どうなるか興味有ります ^^
Claimed Identifier はエンドユーザが所有していると主張するアドレスで、これは引き合いの通り、エンドユーザの自由であると思われ
ます
OP は、その User-Supplied Identifie が鈴木一郎さんか鈴木次郎さんのどちらの物であることを RP に知らせればいいと
言うことだと思います(あってますか？)
# その際に使われるのが、フラグメントなどの識別子なんだと思います..
ですが、User-Supplied Identifier は この場合、フラグメントなしで有ると想像することが出来ますよね？
Yahoo! JAPAN などは、User-Supplied Identifier に「https://me.yahoo.co.jp/a/
XXXXX39TV.B8ViMk8P4qVtiTEciC 」とを使えと言っている様です（そういう風に見えます）
# ここが自分の考え方のおかしいところか..
## 自分の Claimed Identifier と User-Supplied Identifier の言い回しが正しくない気がする..
で、吉松さんのがおっしゃるように「表示するときはとっちゃえばいいじゃんと。」と考えました
自営の RP では、崎村さんのおっしゃるように「主張識別子(Claimed Identifier)を調べ、これをデータベースに登録する」様にし
たいと考えます
鈴木一郎さんの知らないうちに Claimed Identifier が鈴木次郎さんの物となった場合が心配になってきましたが..
まぁ、 Yahoo! JAPAN の場合、何かのハッシュになっているようなので重複することは考えにくいのでしょうが..
--
JanRain のフレームワークでは、わざわざ getDisplayIdentifier() 関数で 表示用の Identifer を提供する
ことが出来るようです
しかし、この getDisplayIdentifier() で帰る Identifier もフラグメントが付いてきます
最初の疑問点はそこで、Ruby などのフレームワークでは表示されないフラグメントを自営の RP で細工しても良いのか？でしたが、「表示するとき
はとっちゃえばいいじゃんと。」の方向で作業しようと思います
Miyagawa さんに最初におしえて頂いたとおり、エンドユーザが User-Supplied Identifier を自営の RP に登録す
る場合、Claimed Identifier と違う事を前提に、OP に確認しに行き、「あなたの Identifier は Claimed
Identifier(ここで言うフラグメント付き)と登録されます」などとすれば良いかな？
この“登録作業”が終わったとは、ログイン認証のみですので、User-Supplied Identifier や、Claimed
Identifier、OP Identifier (であってますか？)の yahoo.co.jp でも利用できるようにします
こんな感じで矛盾のない運用が出来るのかなぁ..
散文ですが、おかしい点など指摘して頂けると助かります
今は、URL Recycling された Claimed Identifier を User-Supplied Identifie が同一な主
張をされた場合、どう処理すればいいか？も気になります
IdP がどう扱うか？次第なのかな..
# 鈴木一郎さんが所有を主張する User-Supplied Identifie なので次郎さんはどうしよう..
## 「Authentication 2.0 以降のみ対応」とすべきなのか..
この辺が仕様を読み切れない不甲斐なさですが、
openid-ja の皆様、もう少しお付き合いして頂けると助かります
Nat Sakimura
まぁ、言ってしまえばその通りだと思います ^^;
>
> とこれはみなさんおっしゃっているとおり、フラグメント付きで格納しておけと。
>
> ですが、
>
> The URL without the fragment should be used when the URL has to be displayed.
>
> 表示するときはとっちゃえばいいじゃんと。
>
先に崎村 さんが記された
この「別のユーザに割り当てたような場合」は、登録されたデータと一致させることが出来ませんので RP でリジェクト処理を行いますが、エンドユーザ
> フラグメントを切り捨てたものは、あくまでユーザ提供識別子であって、Claimed Identifier として取り扱うことはできません。
>
> この仕様は、OPがあるURLを別のユーザに割り当てたような場合(URL Recycling）に対応するために2.0で追加されたセキュリティ機能です。
には事由が判りませんよね？
そう言う事象が起きないように OP が担保している訳では無いと言うことですよね？
「別のユーザに割り当てたような場合」が想定されていると言うことは、容易に想像できます
たとえば鈴木一郎さんが所有を主張した http://www.example.com/suzuki/ を手放し、鈴木次郎さんが同じ OP で同じ
ようにID を取得した場合、フラグメントなどの情報がないと一意であることを担保できません
# URL Recycling は多分そう言うことですよね？
## 鈴木一郎さんと鈴木次郎さんが同じサービスを利用する場合どうなるか興味有ります ^^
Claimed Identifier はエンドユーザが所有していると主張するアドレスで、これは引き合いの通り、エンドユーザの自由であると思われ
ます
OP は、その User-Supplied Identifie が鈴木一郎さんか鈴木次郎さんのどちらの物であることを RP に知らせればいいと
言うことだと思います(あってますか？)
# その際に使われるのが、フラグメントなどの識別子なんだと思います..
ですが、User-Supplied Identifier は この場合、フラグメントなしで有ると想像することが出来ますよね？
Yahoo! JAPAN などは、User-Supplied Identifier に「https://me.yahoo.co.jp/a/
XXXXX39TV.B8ViMk8P4qVtiTEciC 」とを使えと言っている様です（そういう風に見えます）
# ここが自分の考え方のおかしいところか..
## 自分の Claimed Identifier と User-Supplied Identifier の言い回しが正しくない気がする..
で、吉松さんのがおっしゃるように「表示するときはとっちゃえばいいじゃんと。」と考えました
自営の RP では、崎村さんのおっしゃるように「主張識別子(Claimed Identifier)を調べ、これをデータベースに登録する」様にし
たいと考えます
鈴木一郎さんの知らないうちに Claimed Identifier が鈴木次郎さんの物となった場合が心配になってきましたが..
まぁ、 Yahoo! JAPAN の場合、何かのハッシュになっているようなので重複することは考えにくいのでしょうが..
--
JanRain のフレームワークでは、わざわざ getDisplayIdentifier() 関数で 表示用の Identifer を提供する
ことが出来るようです
しかし、この getDisplayIdentifier() で帰る Identifier もフラグメントが付いてきます
最初の疑問点はそこで、Ruby などのフレームワークでは表示されないフラグメントを自営の RP で細工しても良いのか？でしたが、「表示するとき
はとっちゃえばいいじゃんと。」の方向で作業しようと思います
Miyagawa さんに最初におしえて頂いたとおり、エンドユーザが User-Supplied Identifier を自営の RP に登録す
る場合、Claimed Identifier と違う事を前提に、OP に確認しに行き、「あなたの Identifier は Claimed
Identifier(ここで言うフラグメント付き)と登録されます」などとすれば良いかな？
この"登録作業"が終わったとは、ログイン認証のみですので、User-Supplied Identifier や、Claimed
Identifier、OP Identifier (であってますか？)の yahoo.co.jp でも利用できるようにします
こんな感じで矛盾のない運用が出来るのかなぁ..
散文ですが、おかしい点など指摘して頂けると助かります
今は、URL Recycling された Claimed Identifier を User-Supplied Identifie が同一な主
張をされた場合、どう処理すればいいか？も気になります
IdP がどう扱うか？次第なのかな..
# 鈴木一郎さんが所有を主張する User-Supplied Identifie なので次郎さんはどうしよう..
## 「Authentication 2.0 以降のみ対応」とすべきなのか..
この辺が仕様を読み切れない不甲斐なさですが、
openid-ja の皆様、もう少しお付き合いして頂けると助かります
LDU05653
鈴木一郎さんと鈴木次郎さんのはなしは、それぞれ example.com と言う仮想の OP で矛盾すること無く ID を取得したとしてもRP
はそれを知るすべはない（有るかもしれませんが）のでは？ということです
その際、セキュリティ識別子として何かしらの情報が来ることになるのだろうと考えないと、区別のしようが RP には無いのではないか？と言うことで
す。
また、ユーザに見せる、見せないの話でもありません
RP が利用している ID とエンドユーザが自分で思っている ID と差異があっては困るのでは？ということです
# 普通の方には URL に #xxxxx と知らない文字が付いて物になってしまった.. と思われたら困ってしまう
先に記した Ruby でフラグメント云々は
JanRain のPHP版以外のフレームワークでのデモ版の話です
http://openidenabled.com/php-openid/trunk/examples/consumer/
これと、
http://openidenabled.com/python-openid/trunk/examples/consumer/
http://openidenabled.com/ruby-openid/trunk/examples/consumer/
# ここの話ですので、悪しからず..
この上の PHP 版とPython,Ruby 版では動作に少し違いがあるが PHP 版を利用したいと考えているので少し困っている..
と言うことです
--
# 以降、２～３日、このグループを確認させて頂けなくなります
## 時間を見つけてなるべく確認するようにしますので、引き続きよろしくお願いします
Tatsuhiko Miyagawa
>
> 鈴木一郎さんと鈴木次郎さんのはなしは、それぞれ example.com と言う仮想の OP で矛盾すること無く ID を取得したとしてもRP
> はそれを知るすべはない（有るかもしれませんが）のでは？ということです
フラグメントがついているから区別できますね。
> また、ユーザに見せる、見せないの話でもありません
> RP が利用している ID とエンドユーザが自分で思っている ID と差異があっては困るのでは？ということです
Yahoo!の場合はユーザが入力するのはyahoo.co.jpですから差異があるのがそもそも当然ですね。
--
Tatsuhiko Miyagawa
LDU05653
引き合いに出してよいか判りませんが、仮定の話ですので..
たとえば、Yahoo! JAPAN 以外で OpenID.ne.jp としましょう
http://LDU05653.openid.ne.jp を僕が現在は所有しています
何らかの要因により、これを手放したとし、その際、個人情報の削除も依頼したとします
悪意の第三者とは限りませんが、偶然などの事由で、別人が LDU05653 を主張したとすると、http://
LDU05653.openid.ne.jp を与えるのだと思います
# もちろん、きちんとしている IdP や OP なら、フラグメントなどで前者と後者を区別できる形にしてくれると思います
----
現在構築中の RP は 7.1. Initiation (開始)
http://lab.koshigoe.jp/en2ja/openid-authentication-2_0.html#initiation
で言うところの User-Supplied Identifier に
yahoo.co.jp と入力されようが、https://me.yahoo.co.jp/a/
XXXXX39TV.B8ViMk8P4qVtiTEciC と入力されようが構いません
# この辺も誤解なきよう..
# むしろ、僕も、短い名前の汎用JP ドメインをいくつか持っていますので積極的に利用したいと考えています
# XXX.jp になりますので、yahoo.co.jp より少し便利 ^^y
# 利便性を考え、顧客にはこっちを使ってもらいたいと考え、現在構築中の RP に積極的に利用しようと考えています
----
引っかかっているのは、
僕が放棄した http://LDU05653.openid.ne.jp と次の http://LDU05653.openid.ne.jp と区
別がつかないのでは..
ということです
実際は http://LDU05653.openid.ne.jp#2 になっていても http://LDU05653.openid.ne.jp
と表示されて利用されていれば、僕は「あれ？消したはずなのに..」となるかもしれない
http://LDU05653.openid.ne.jp を現在所有している人は、「あれ、こんなところで何で利用履歴があるんだ？」とならないか
なぁ..
とまぁ、こんなレベルの話です
OP や IdP がフラグメントに関する情報を見える形にしてくれないと、RP のシステム内部の情報を確認できない場合
http://LDU05653.openid.ne.jp#1 と http://LDU05653.openid.ne.jp#2 の圧縮された表
示からは http://LDU05653.openid.ne.jp としか判らないので扱いに苦慮するのでは..
この逆も然りで
http://LDU05653.openid.ne.jp と登録されるはずなのに 何で http://LDU05653.openid.ne.jp#2
だろう？
という、いらぬ杞憂かもしれない話です
----
# JanRain のところの PHP 版は版が進んでいないようですので、まぁ、不都合が内包されているのかなぁ..とも思っていますが ^^;
Nat Sakimura
Tatsuya Katsuhara
こんにちは。
考えさせられるテーマだったので、ちょっと持論で、しかも長文で散文ですが書いてみます。
まず、yahoo.co.jpの動作を見ます。
YahooのOpenID(op identifierじゃないです)を入力すると、RPからはopenid.claimed_id,
openid.identityともに同一のフラグメント無しの値で送信されます。しかしOPからはopenid.claimed_idにフラグメントが付与されて帰ってきます。ライブラリを読んではいませんが、おそらくこの値を返しています。
そこで、吉松さんのメールにある参照先をみると、OPはOpenID Identity URLにフラグメントを足しても良いよと言っている。
しかしこれをUser-supplied
Identifierとして利用すると、RPはフラグメントを除去してDiscoveryしなければならない。それにもかかわらずyahoo.co.jpのようなOPはAuth
responseのopenid.claimed_idにフラグメントを付与してくる。
ということで、私は下記のように考えています
■大前提
「RPは入力されたUser-supplied Identifierから派生するIdentifierの中でもっとも一意性が高いものを記録すべきである。」
「OPが直接返してきた値を記録すべきである。」
と考えています。
■User-supplied IdentifierがXRIだったら
識別子がXRIの場合を考えると、User-supplied
Identifierはあくまでその時点でユーザが所有していると思っているIdentifierであれば良くて、ReassignableでもPersistentでも良いわけです。URLの場合はUser-supplied
Identifierは正規化されてフラグメントも除去されてとありますが、XRIの場合はCanonical
IDですとあります。Canonical
IDはPersistentなものだとあります。XRIにおけるPersistentとは「時間と空間」の2軸においてGloba
Uniqueかつnot-reassignableということですので、RPはAuth
request中のopenid.claimed_id(Canonical ID)をそのまま覚えておけば、たとえUser-supplied
IdentifierがReassginableなもので所有者が移っていたとしても、本質的なユーザーの違いを考慮することができます。
■User-supplied IdentifierがURLだったら
一方、User-supplied IdentifierがURLだった場合は・・・正規化されてフラグメント除去されてClaimed
Identifierになりますが、これって結局、LDU05653さんの仰るようにID発行元のポリシーによってReassignableですよね。http://example.com/suzukiを所有する鈴木さんが解約してID
recycleして別の鈴木さんに使わせてあげるような場合です。つまり、ここでOPが一意発行ポリシーを取っているならば、claimed
identifierを記録してしまえば良いと思います。auth responseのopenid.claimed_idですね。
しかしながら本質的にはドメイン名自体がReassinableなので、URLのClaimed
Identifierそのものは本質的にReassinableですが・・・（ただし時系列的には所有する本質なユーザは一意です。）
■OPが発行するOpenID URLがReassignableだったら
本質的なURL Claimed IdentifierのReassinable性はあらめるとして、次にOPがOpenID URL(user
id)の再利用発行ポリシーを採っている場合を考えます。
RPはUser-supplied Identifierを正規化して得られるClaimned
Identifierをそのまま記憶したところで、時系列的に別のタイミングでの所有権を持つユーザと、過去に所有権を持っていたユーザとの区別はつきません。しかしながら、今回のyahoo.co.jpの実装では、Auth
responseのopenid.claimed_idの値には管理番号ともとれるフラグメントが付与されており、この付加情報により一意性を担保していると予想するならば、Auth
responseのopenid.claimed_idをフラグメントが付いたまま記録しておくべきという、崎村さんの仰る方法にすべきだと思います。
ある時点での所有者のOpenID URLを（OpenID URL +
所有者固有番号）という本質的なユーザへマッピングができるのはOPだけですから、OPの返した値を記録すべきですね。
その次はOP-local Identifierですが・・・そこまで考えると頭が壊れそうなので、今回はやめます。。。
■結論？
0. OPはAuth responseのopenid.claimed_idでglobal uniqueなものを返すべきである。
1. OPは可能な限りリサイクル不能なOpenID URLを提供すべきである。しかしそれをフラグメントによって表現し、ユーザへ提供することは無意味である。
2. 少なくともOPはAuth response中のopenid.claimed_idでは時間と空間的に一意なOpenID
URLを返すべきである。この際のOpenID URLにはフラグメントを利用しても良い。
3. RPは上記の0に加えて1か2を満たしたOPからのAuth response中のopenid.claimed_idを記録すべきである。
4. ドメイン名のReassignable性がopenid.claimed_idのglobal unique性に与える影響は、さわやかに諦める。
なんというか、勝手OPの発行したOpenID URLなんて使う気にもなりません。
だって、自分が持っていたOpenID
URLが再割り当てされて、たまたま自分が利用していたRPサイトのアカウントに、どこかの誰かにログインされちゃう可能性があるんですから。
このあたりのベストプラクティスを考える上でも、一定の指針を打ち出すような必要があるのかもしれませんね。
--
=katsu
http://xri.net/=katsu/(+contact)
http://xri.net/=katsu/(+blog)
Tatsuhiko Miyagawa
> 「OPが直接返してきた値を記録すべきである。」 と考えています。
そうですね。
> ■User-supplied IdentifierがURLだったら
> 一方、User-supplied IdentifierがURLだった場合は・・・正規化されてフラグメント除去されてClaimed
> Identifierになりますが、
ちがいます。正規化するのは*RPが* discovery するときにフラグメントを除去するのであって、OP からわたってきた Claimed
Identifier を正規化してはいけません。
> RPはUser-supplied Identifierを正規化して得られるClaimned
> Identifierをそのまま記憶したところで、時系列的に別のタイミングでの所有権を持つユーザと、過去に所有権を持っていたユーザとの区別はつきません。
Claimed Identifier をそのまま記憶すれば、フラグメントがついていますからユーザの区別がつきます。
> しかしながら、今回のyahoo.co.jpの実装では、Auth
> responseのopenid.claimed_idの値には管理番号ともとれるフラグメントが付与されており、この付加情報により一意性を担保していると予想するならば、
予想するならば、というか、そのためのフラグメント仕様なのだと思いますが。
> ある時点での所有者のOpenID URLを（OpenID URL +
> 所有者固有番号）という本質的なユーザへマッピングができるのはOPだけですから、OPの返した値を記録すべきですね。
そのとおりですね。
> 1. OPは可能な限りリサイクル不能なOpenID URLを提供すべきである。しかしそれをフラグメントによって表現し、ユーザへ提供することは無意味である。
上記の理由により無意味ではないと思います。できる限りリサイクル不能な URL
を提供するのがベストプラクティスであることには同意しますが、それは OP の requirement
ではありません。これは１年ぐらい前に本家で話題になっていますので、興味があればどうぞ。
http://openid.net/pipermail/general/2007-May/002407.html
> なんというか、勝手OPの発行したOpenID URLなんて使う気にもなりません。
> だって、自分が持っていたOpenID
> URLが再割り当てされて、たまたま自分が利用していたRPサイトのアカウントに、どこかの誰かにログインされちゃう可能性があるんですから。
フラグメントを除去して格納してしまうような実装の RP を使う気にならない、というほうが正しいのでは？
それを利用者側がどのようにチェックすればいいのか、というのは興味深い問題かもしれませんね。
--
Tatsuhiko Miyagawa
Tatsuhiko Miyagawa
On 4/5/08, Tatsuhiko Miyagawa <miya...@gmail.com> wrote:
> > ■User-supplied IdentifierがURLだったら
> > 一方、User-supplied IdentifierがURLだった場合は・・・正規化されてフラグメント除去されてClaimed Identifierになりますが、
>
> ちがいます。正規化するのは*RPが* discovery するときにフラグメントを除去するのであって、OP からわたってきた Claimed Identifier を正規化してはいけません。
ごめんなさい、ここ読み違えてました。OP で認証する前に normalize かけて (フラグメント除去して) Claimed
Identifier になる、というのは正しいです。で、リサイクルされていた場合、その値を利用してしまうと（フラグメントがないので）その時点で以前の所有者と同一人物かどうか
RP にはわからない、というのも正しいですね。
# katsu さんの話はこの１箇所だけなんかおかしいなと思っていたのですが単に私が読み違えてました、すいません。
--
Tatsuhiko Miyagawa
Tatsuya Katsuhara
> > 一方、User-supplied IdentifierがURLだった場合は・・・正規化されてフラグメント除去されてClaimed
> > Identifierになりますが、
>
>
> ちがいます。正規化するのは*RPが* discovery するときにフラグメントを除去するのであって、OP からわたってきた Claimed
> Identifier を正規化してはいけません。
>
2.0のTerminologyだけを見てそう解釈していました。あまり英語は得意ではありませんが、それにしてもこの表現は微妙ですね。
Claimed Identifier:
* The Identifier obtained by normalizing (Normalization) the
User-Supplied Identifier, if it was an URL.
> > しかしながら、今回のyahoo.co.jpの実装では、Auth
> > responseのopenid.claimed_idの値には管理番号ともとれるフラグメントが付与されており、この付加情報により一意性を担保していると予想するならば、
>
>
> 予想するならば、というか、そのためのフラグメント仕様なのだと思いますが。
おっと、たしかにそんな仕様が書いてありますね。
根本的に知らずに長文を書いてしまいました・・・
> 上記の理由により無意味ではないと思います。できる限りリサイクル不能な URL
> を提供するのがベストプラクティスであることには同意しますが、それは OP の requirement
> ではありません。これは１年ぐらい前に本家で話題になっていますので、興味があればどうぞ。
> http://openid.net/pipermail/general/2007-May/002407.html
>
ありがとうございます。見てみますね。
>
> > なんというか、勝手OPの発行したOpenID URLなんて使う気にもなりません。
> > だって、自分が持っていたOpenID
> > URLが再割り当てされて、たまたま自分が利用していたRPサイトのアカウントに、どこかの誰かにログインされちゃう可能性があるんですから。
>
>
> フラグメントを除去して格納してしまうような実装の RP を使う気にならない、というほうが正しいのでは？
ここでは勝手OPは結局管理も行き届いておらず、フラグメント付与していようと重複させてくることもあるでしょうという、どうしようもないOPのことを指しています。
でも、仰るとおりそんなRPは使う気にはならないですね。プロプライエタリの場合、ユーザーがそれを認識するのは簡単ではなさそうですが・・・
Tatsuhiko Miyagawa
> > Identifier を正規化してはいけません。
> おっと、失礼しました。
この後に自己レスしてしまいましたが、僕のほうでフェーズを勘違いしていました。間違いではありません。すいません。
> Authentication
> 2.0のTerminologyだけを見てそう解釈していました。あまり英語は得意ではありませんが、それにしてもこの表現は微妙ですね。
> Claimed Identifier:
> * The Identifier obtained by normalizing (Normalization) the
> User-Supplied Identifier, if it was an URL.
そうなんですよね。仕様書では、Claimed Identifier という言葉が、認証プロセスを通して使われていて、
Claimed Identifier: An Identifier that the end user claims to own; the
overall aim of the protocol is verifying this claim.
となっていて「最初に入力され、正規化された Claimed Identifier
が確かにそのユーザのものであるかを確認するのがこのプロトコルである」となっていますが、実際には、
7.2 This final URL MUST be noted by the Relying Party as the Claimed
Identifier and be used when requesting authentication (Requesting
Authentication).
11.5 The Claimed Identifier in a successful authentication response
SHOULD be used by the Relying Party as a key for local storage of
information about the user. The Claimed Identifier MAY be used as a
user-visible Identifier. When displaying URL Identifiers, the fragment
MAY be omitted.
の２つの場面で Claimed Identifier
が異なる値になっているケース（このスレッドでさんざん話題になっている例だとフラグメント有無）もあるので、ここが混乱を生じさせているという気がしますね。
OpenID 1.x では URL の Identification だけだったプロトコルに、Authentication
を追加したためにここの説明というか用語の使い方が紛らわしいものになっている、のかもしれません。
--
Tatsuhiko Miyagawa
LDU05653
# 流れを分断してしまうようで申し訳ありません
=katsu さんや Miyagawa さんなどが仰っていることを、“暴力的に極言すると”（悪しからず..）、“OP も RP も信用できるモ
ノ以外使用するな！”に行き着いてしまうのでしょうか..
また、“OP も RP も、OpenID に関するポリシーをご自分で確認し、ご自分で利用意志と利用意図を勘案するように！”（極言続き..）
になるのでしょうか..
#その通りなんでしょうが..
Yahoo! JAPAN などのように、別に個人を特定できる情報を既に持っている状況で “OpenID をどうぞ！”の様な場合と、
OpenID.ne.jp などの様に、“あなたが主張する（覚えやすい/わかりやすい？） OpenID をどうぞ！”の違いになるのでしょう
か..
# Yahoo! JAPAN の OpenID には LDU05653 の文字が入ってくるのだと最初は思ってました ^^;
## 私が与えた Claimed Identifier をあなたに貸した物だと認めてあげるよ！っていう感じでしょうか
-----
> ■大前提
> 「RPは入力されたUser-supplied Identifierから派生するIdentifierの中でもっとも一意性が高いものを記録すべきである。」
> 「OPが直接返してきた値を記録すべきである。」
だと思いますが、それが難しいですし、“一意性が高いもの”を、どう判断するか！と、その根拠ですよねぇ..
僕の考えている杞憂の部分は、Yahoo! JAPAN の OpenID を提供する側のポリシーと、僕が考えている提供される OpenID の利
用方法に関するポリシーの違いに帰結してしまうのだと思いますが..
Yahoo! JAPAN は一意性の高い物を持っているのに“見せてくれない”が、僕はそれを表示しないといけないと思っている
と言うことなのでしょう
見せてくれないのは、見せる必要がないからだと考えるのも妥当です..
結局の所、“用途に応じて OpenID を使い分ける”になるので、RP にきちんと通達せずに使用を停止した、鈴木一郎さんも悪いし、知らない利用
履歴情報があるのに放置した鈴木次郎さんも悪いし、定期的に身元確認をしなかった RP を管理する僕も悪い！
# もちろん、意図的にネガティブな方向に向けた極論ですよ ^^;
かなぁ..
-----
良い方に考えれば、
OP は global unique な ID を発行してもらえるか、エンドユーザが意図した ID を発行してもらえるような OP を自身で選
択してもらい、
RP は、「あなたの個人情報として、（“11.5. Identifying the end user”で言うところの） Claimed
Identifier を利用します」などと表明し、併せて定期的に、Claimed Identifier の更新をしてもらうようにエンドユーザに
促す方法を併設して、時系列上の問題点が発生しないように注意する
こんな風にできればいいのかなぁ..
-----
OP を選択するのはエンドユーザで有るべきなんでしょうが、最終的に RP が OP を限定せざるを得なくなり、OP は RP を選別する様な、
良くないスパイラル状の思考に成ってしまいそうです
-----
フレームワークの部分は、何方か、英語できちんと意志の疎通を図れる方にお願いできれば助かりますが、それがバグかどうかは私には判断できません
# すいません。自分は英語が出来ないモノで.. ^^;
## ここまでの流れでは、フラグメント表示の有無は読み手・作り手の裁量に依るような気がしますが、さて..
Nat Sakimura
LDU05653
相変わらず、散文ですが、こんな感じでしょうか
不勉強な点は指摘して頂けると助かります
-----
・リサイクリングされた ID を含め、ID の一意性を担保する部分が不透明なので、時系列を扱う必要のあるシステムを構築する際に、システム側で担
保する必要があるのではないのか？
-> こちらで指定した“物”を ID として利用してくれるとわかりやすいが (1.1) 、自由度が上がった分、難解になった (2.0)
<- OP が設定した ID を、PR が任意の時点で一意であるか確認する術がないのでは？
<- 一定期間ごとに RP 側で ID が継続的に利用されている物か確認する必要があるか？
・システム内部で扱う情報とエンドユーザが視認できる情報に差異があり、その乖離が大きい場合は、インターネットの利用に不慣れなエンドユーザを想定し
にくいのではないか？
-> OP や RP の指針により表示情報などに差異があり、エンドユーザを混乱させるかもしれない
<- 最初の疑問点で、OP が表明した情報と、RP が入手し表示すべき情報の差異が容認されているが明確な指針がないのでは？
<- 想定として部門サーバなどで ID を管理した場合、管理者の資質に関して問題があ場合の対処などにコストがかかるかもしれない？
-----
以上、二点とそれらに関連する懸案です
以下は補足です
# に続く文は、行間（ぼやき）を示しますので読み飛ばしてください
-----
最初の部分は、普通のメールアドレスなどでも同じですよね？
URL やメールアドレスでも再利用はされます
同様に、利用する側で誤用しないように、留意したシステム設計をすればいいのだと思いますが、コストがかさみます
# 短ければ短いほど判り難く、再利用が認識されるのは、そのサイトに訪問したり、メールを送ってからですよね..
--
次に、最初の疑問点と派生した疑問ですが、ポリシーの摺り合わせが出来ればいいのでは！と思います
ホワイトリストやレーティングなどでポリシーの差異の少ないところを選択できるようになれば良いかも知れません
# OP の評価ポイントが細分化されて、RP はその評価ポイントを利用できれば良いかもしれません
# しかし、限定されたユーザにサービスを提供する RP の評価はどうなるのか判りません
Yahoo! JAPAN の ID の様な場合、URL のスキームからクエリ/フラグメントをのぞく部分までが一意で有るか確認できません
ですが、Yahoo! のフラグメントの様な、単純化された桁の少ない数字などは認識しやすいのに、表示されないので視認できません
一方、OpenID.ne.jp の ID の様な場合、エンドユーザーは URL を一目で確認することが出来ますが、
RP は、その ID を確認した時点で、過去の ID との連続した一意性を確認できるか不明なのでは？と言う点です
# 誤解を恐れずに言えば、過去、Yahoo! JAPAN で系列企業を通じた ID の流出があったと記憶していますが、ID の法則性が不明な以
上、無条件で信用することは出来ないですよね..
## もちろん、現状ではこの様なことはないと考え ID などを登録していますので悪しからず!
どちらも、エンドユーザに誤解を与える場合が有るのではないかと考えてしまいます
また、OP を信用できるか否か？RP を信用してもらえるか否か？に帰結してしまうかも知れません
-----
Cookie などを利用し、「7.1. Initiation 」で言う、User-Supplied Identifier の初期値
を“yahoo.co.jp”などとした場合、最短では、マウスのクリックを二回するだけで認証することが出来ます
ログイン認証の利便性向上には欠かせませんので、これを現在構築中のシステムに組み込もうと思ったのが発端です
今後のInternet Explorer や Mozilla FireFox などのユーザ・エージェントなどもますます便利に使えるようになると
おもいます
-----
# openid-japan.org などには、RP などの構築ガイドなど期待したいです ^^
Nat Sakimura
そうですねぇ
相変わらず、散文ですが、こんな感じでしょうか
不勉強な点は指摘して頂けると助かります
-----
・リサイクリングされた ID を含め、ID の一意性を担保する部分が不透明なので、時系列を扱う必要のあるシステムを構築する際に、システム側で担
保する必要があるのではないのか？
-> こちらで指定した"物"を ID として利用してくれるとわかりやすいが (1.1) 、自由度が上がった分、難解になった (2.0)
<- OP が設定した ID を、PR が任意の時点で一意であるか確認する術がないのでは？
<- 一定期間ごとに RP 側で ID が継続的に利用されている物か確認する必要があるか？
・システム内部で扱う情報とエンドユーザが視認できる情報に差異があり、その乖離が大きい場合は、インターネットの利用に不慣れなエンドユーザを想定し
にくいのではないか？
-> OP や RP の指針により表示情報などに差異があり、エンドユーザを混乱させるかもしれない
<- 最初の疑問点で、OP が表明した情報と、RP が入手し表示すべき情報の差異が容認されているが明確な指針がないのでは？
<- 想定として部門サーバなどで ID を管理した場合、管理者の資質に関して問題があ場合の対処などにコストがかかるかもしれない？
-----
以上、二点とそれらに関連する懸案です
以下は補足です
# に続く文は、行間（ぼやき）を示しますので読み飛ばしてください
-----
最初の部分は、普通のメールアドレスなどでも同じですよね？
URL やメールアドレスでも再利用はされます
同様に、利用する側で誤用しないように、留意したシステム設計をすればいいのだと思いますが、コストがかさみます
# 短ければ短いほど判り難く、再利用が認識されるのは、そのサイトに訪問したり、メールを送ってからですよね..
--
次に、最初の疑問点と派生した疑問ですが、ポリシーの摺り合わせが出来ればいいのでは！と思います
ホワイトリストやレーティングなどでポリシーの差異の少ないところを選択できるようになれば良いかも知れません
# OP の評価ポイントが細分化されて、RP はその評価ポイントを利用できれば良いかもしれません
# しかし、限定されたユーザにサービスを提供する RP の評価はどうなるのか判りません
Yahoo! JAPAN の ID の様な場合、URL のスキームからクエリ/フラグメントをのぞく部分までが一意で有るか確認できません
ですが、Yahoo! のフラグメントの様な、単純化された桁の少ない数字などは認識しやすいのに、表示されないので視認できません
一方、OpenID.ne.jp の ID の様な場合、エンドユーザーは URL を一目で確認することが出来ますが、
RP は、その ID を確認した時点で、過去の ID との連続した一意性を確認できるか不明なのでは？と言う点です
# 誤解を恐れずに言えば、過去、Yahoo! JAPAN で系列企業を通じた ID の流出があったと記憶していますが、ID の法則性が不明な以
上、無条件で信用することは出来ないですよね..
## もちろん、現状ではこの様なことはないと考え ID などを登録していますので悪しからず!
どちらも、エンドユーザに誤解を与える場合が有るのではないかと考えてしまいます
また、OP を信用できるか否か？RP を信用してもらえるか否か？に帰結してしまうかも知れません
-----
Cookie などを利用し、「7.1. Initiation 」で言う、User-Supplied Identifier の初期値
を"yahoo.co.jp"などとした場合、最短では、マウスのクリックを二回するだけで認証することが出来ます
ログイン認証の利便性向上には欠かせませんので、これを現在構築中のシステムに組み込もうと思ったのが発端です
今後のInternet Explorer や Mozilla FireFox などのユーザ・エージェントなどもますます便利に使えるようになると
おもいます
-----
# openid-japan.org などには、RP などの構築ガイドなど期待したいです ^^