[rfc] OpenID Membership Authentication Method
10 views
Skip to first unread message
小山浩之
Aug 26, 2008, 9:16:48 AM8/26/08
to openid-ja
株式会社ミクシィの小山です。はじめまして。
OpenIDの枠組みの中でメンバーシップ認証を実現する仕様というか手順をザックリと書いてみました。コメントなど頂けると幸いです。
http://developer.mixi.co.jp/draft/openid-membership-authentication-method-draft-1
弊社のOpenIDベースの認証サービス「mixi OpenID」では、OpenIDによるエンドユーザ認証だけでなく、エンドユーザどうしの関係を
認証する「マイミクシィ認証」と、特定グループの所属を認証する「コミュニティ認証」という関係認証サービスを提供しています。
http://developer.mixi.co.jp/openid/spec
この関係認証サービスの仕様を一般化して、OpenIDの枠組みの中で「メンバーシップ認証」を実現する方式としてまとめたのが上記のドキュメントで
す。ここではOpenID Provider(OP), Relying Party(RP)の他に、新たにMembership
Provider(MP)という要素を定義して、グループの定義とそのグループ参加者のメンバーシップを認証するサービスをRPに提供します。この仕組
みを使って、LANの情報サービスへのアクセス制御を集中および分散管理するOpenIDベースの認証サーバの実装などなどにも応用できると考えていま
す。
ちなみに。「mixi OpenID」の場合はOPと同じ場所でMPを提供する形態をとっていますが、OPからMPを切り離した構成(IMP -
Independent Membership Provider)でメンバーシップ認証だけを提供するサービスも実現できます。
______________
Hiroyuki OYAMA <oy...@mixi.co.jp>, <oy...@module.jp>
OpenIDの枠組みの中でメンバーシップ認証を実現する仕様というか手順をザックリと書いてみました。コメントなど頂けると幸いです。
http://developer.mixi.co.jp/draft/openid-membership-authentication-method-draft-1
弊社のOpenIDベースの認証サービス「mixi OpenID」では、OpenIDによるエンドユーザ認証だけでなく、エンドユーザどうしの関係を
認証する「マイミクシィ認証」と、特定グループの所属を認証する「コミュニティ認証」という関係認証サービスを提供しています。
http://developer.mixi.co.jp/openid/spec
この関係認証サービスの仕様を一般化して、OpenIDの枠組みの中で「メンバーシップ認証」を実現する方式としてまとめたのが上記のドキュメントで
す。ここではOpenID Provider(OP), Relying Party(RP)の他に、新たにMembership
Provider(MP)という要素を定義して、グループの定義とそのグループ参加者のメンバーシップを認証するサービスをRPに提供します。この仕組
みを使って、LANの情報サービスへのアクセス制御を集中および分散管理するOpenIDベースの認証サーバの実装などなどにも応用できると考えていま
す。
ちなみに。「mixi OpenID」の場合はOPと同じ場所でMPを提供する形態をとっていますが、OPからMPを切り離した構成(IMP -
Independent Membership Provider)でメンバーシップ認証だけを提供するサービスも実現できます。
______________
Hiroyuki OYAMA <oy...@mixi.co.jp>, <oy...@module.jp>
Tatsuki Sakushima
Aug 27, 2008, 2:56:16 PM8/27/08
to openid-ja
Mixi 小山様
NRIパシフィック 作島（さくしま）ともうします。
はじめまして、よろしくお願いいたします。
Membership Authentication Methodの仕様、興味深く拝見させて
いただきました。是非、「日本発世界へ」への仕様にしてください。
（Membership Authentication MethodはMAMと略します。）
以下、末筆ながら気がついた点をまとめてみました：
①「メンバーシップ」という表現について
ソーシャルサイトでの友人関係も扱えると思うので、
メンバーシップよりはより広い概念を包括しているのかな？
と思いました。そうなると、RelationshipとかSocialという
表現のほうが適切かなと思いました。（注：主観入ってます。）
用語決定については英語圏の人を巻き込むと良いですね。
②「認証リクエスト」の部分
MAMでは、RPオーナーが各種識別子を指定することになると思いますが、
OpenID畑から来た人が読むと、「どこでユーザーはOpenIDを入力するのか？」
と思っています。この点ははっきり強調されたほうが良いと思いました。
③「付録A.1」のユーザー識別子
上に関係しますが、「付録A.1」で「あるエンドユーザーは自身の識別子として
"http://www.example.com/"を用いる」とありますが、MAMではこれは「MP識別子」に
なるのではないでしょうか？MAMは普通のOpenID認証と違うと思いますので。
このURLはユーザーの持ち物ではありませんね？OpenID2.0の仕様を読むと、
Claimed IDは「An Identifier that the end user claims to own」とあります。
④その他気になった点
瑣末になりますが、2点あります：
１．RPから見てMPが複数ある場合の実装はどうなるのだろうか？と考えました。
ユーザーがRPが誰か判断して、その人とつながりのあるMPを選択するという
ユースケースもあるのかな？と。
（あんまりユースケースを広げすぎると仕様が複雑になるという弊害があるのは
理解しているのですが、この仕様をUSのコミュニティに出したときにどういう
反応がありそうか？気になりました。こっちだと、みんなLinkedIn、Plaxo、
MySpe、など普通に併用していますので。）
２．MAMで使う識別子がそろった場合、人の設定を勝手に使えてしまうのかな？
と思ったのですが。RPが誰か特定するのは、とても難しいのですが。。。
今の仕様のままでニックネーム以外のSregは返さない方が良さそうです。
以上です。
> OpenIDの枠組みの中でメンバーシップ認証を実現する仕様というか手順をザックリと書いてみました。コメントなど頂けると幸いです。http://developer.mixi.co.jp/draft/openid-membership-authentication-me...
NRIパシフィック 作島（さくしま）ともうします。
はじめまして、よろしくお願いいたします。
Membership Authentication Methodの仕様、興味深く拝見させて
いただきました。是非、「日本発世界へ」への仕様にしてください。
（Membership Authentication MethodはMAMと略します。）
以下、末筆ながら気がついた点をまとめてみました：
①「メンバーシップ」という表現について
ソーシャルサイトでの友人関係も扱えると思うので、
メンバーシップよりはより広い概念を包括しているのかな？
と思いました。そうなると、RelationshipとかSocialという
表現のほうが適切かなと思いました。（注：主観入ってます。）
用語決定については英語圏の人を巻き込むと良いですね。
②「認証リクエスト」の部分
MAMでは、RPオーナーが各種識別子を指定することになると思いますが、
OpenID畑から来た人が読むと、「どこでユーザーはOpenIDを入力するのか？」
と思っています。この点ははっきり強調されたほうが良いと思いました。
③「付録A.1」のユーザー識別子
上に関係しますが、「付録A.1」で「あるエンドユーザーは自身の識別子として
"http://www.example.com/"を用いる」とありますが、MAMではこれは「MP識別子」に
なるのではないでしょうか？MAMは普通のOpenID認証と違うと思いますので。
このURLはユーザーの持ち物ではありませんね？OpenID2.0の仕様を読むと、
Claimed IDは「An Identifier that the end user claims to own」とあります。
④その他気になった点
瑣末になりますが、2点あります：
１．RPから見てMPが複数ある場合の実装はどうなるのだろうか？と考えました。
ユーザーがRPが誰か判断して、その人とつながりのあるMPを選択するという
ユースケースもあるのかな？と。
（あんまりユースケースを広げすぎると仕様が複雑になるという弊害があるのは
理解しているのですが、この仕様をUSのコミュニティに出したときにどういう
反応がありそうか？気になりました。こっちだと、みんなLinkedIn、Plaxo、
MySpe、など普通に併用していますので。）
２．MAMで使う識別子がそろった場合、人の設定を勝手に使えてしまうのかな？
と思ったのですが。RPが誰か特定するのは、とても難しいのですが。。。
今の仕様のままでニックネーム以外のSregは返さない方が良さそうです。
以上です。
> OpenIDの枠組みの中でメンバーシップ認証を実現する仕様というか手順をザックリと書いてみました。コメントなど頂けると幸いです。http://developer.mixi.co.jp/draft/openid-membership-authentication-me...
小山浩之
Sep 2, 2008, 12:57:19 AM9/2/08
to open...@googlegroups.com
作島さんコメントありがとうございます。遅くなりま
した。
# http://openid-japan.org/ のサーバについて残念なお知らせ
が出てました。
On 2008/08/28, at 3:56, Tatsuki Sakushima wrote:
> ㈰「メンバーシップ」という表現について
>
> ソーシャルサイトでの友人関係も扱えると思うの
> で、
> メンバーシップよりはより広い概念を包括している
> のかな？
> と思いました。そうなると、RelationshipとかSocialとい
> う
> 表現のほうが適切かなと思いました。（注：主観
> 入ってます。）
> 用語決定については英語圏の人を巻き込むと良いで
> すね。
そうですね。当初は「関係認証」等とも呼んでいたの
でRelationshipも候補に挙げていましたが、mixi OpenIDのモ
デルは実際には「関係の認証」ではなく「集合への所属」の認
証だったのでドラフトではMembershipを選びました。こ
のへんは崎村さんが gen...@openid.net にpostして頂いたの
をきっかけに、ディスカッションが進めば...とか思っ
たのですが、悲しいことに反応無いですね。
ちなみにソーシャルグラフを扱うアプリケーションで
は関係というプリミティブな要素ももちろん扱います
が、大部分のケースでは「特定の集合に属しているか
否か」程度の大雑把なモデルの方が扱いやすいと私は
考えています。また企業内の情報システムで使うACL的
なものをMAMで実装する場合にも言えるのではないかと
思っています。
> ㈪「認証リクエスト」の部分
>
> MAMでは、RPオーナーが各種識別子を指定することに
> なると思いますが、
> OpenID畑から来た人が読むと、「どこでユーザーは
> OpenIDを入力するのか？」
> と思っています。この点ははっきり強調されたほう
> が良いと思いました。
なるほど。ここはMAMを使うOP/MP/RPが実現したいものに
よって変わってくることを想定して明言していません
でした。通常はRP上でMAMを適用したい情報の所有者or
管理者がグループ識別子をセットしますが、可能性と
してエンドユーザによるuser-suppliedなグループ識別子
を使う場合もあるのかなと思っています。
# RPとしてはとても使いにくいとは思いますが :-P
となるとこんな感じでしょうか。
訂正前: RPは認証したいグループ識別子からMP終点URLを
探索する。
訂正案A: RPは管理者が指定したグループ識別子からMP
終端URLを探索する。
訂正案B: RPはエンドユーザが入力、または管理者が指
定したグループ識別子からMP終端URLを探索する。
む、この場合、RPオーナーなどを指す「管理者」って
言葉が未定義でした。用語への追加が必要。
> ㈫「付録A.1」のユーザー識別子
が暗にぶつかっているので、例として不適切ですね。
おそらく下記のような感じにID例を書き換えると誤解
の余地が無くなりそうですね。
"http://www.example.com/" -> "http://www.example.com/foo"
"http://www.example.com/friends" -> "http://www.example.com/foo/friends"
"http://www.example.com/friends/female" -> "http://www.example.com/foo/friends/female
"
"http://www.example.com/friends/male" -> "http://www.example.com/foo/friends/male
"
"http://www.example.com/Example.Inc" -> "http://www.example.com/foo/Example.Inc
"
> ㈬その他気になった点
>
> 瑣末になりますが、2点あります：
>
> １．RPから見てMPが複数ある場合の実装はどうなるの
> だろうか？と考えました。
> ユーザーがRPが誰か判断して、その人とつながりの
> あるMPを選択するという
> ユースケースもあるのかな？と。
> （あんまりユースケースを広げすぎると仕様が複雑
> になるという弊害があるのは
> 理解しているのですが、この仕様をUSのコミュニ
> ティに出したときにどういう
> 反応がありそうか？気になりました。こっちだ
> と、みんなLinkedIn、Plaxo、
> MySpe、など普通に併用していますので。）
このへんは未定義です。MAMのXRDSでの記述について書
き入れるのを忘れていたのですが、OPのXRDSのサービス
型にMAMを追加することで、RP側でMPを最低限レコメン
ドする余地が残ると思います。あと、異なるMPのグ
ループ識別子を包括して提供するMP Aggregation serviceも
この枠組みで実現できるとおもっているので、実現可
能なシステムを付録Bで提案してあとは作り手の想像
力に任せた方が面白いかなとも思いました。
もうちょっと適切な誘導(?)方法があったら是非教えて
ください。
> ２．MAMで使う識別子がそろった場合、人の設定を勝
> 手に使えてしまうのかな？
> と思ったのですが。RPが誰か特定するのは、とても
> 難しいのですが。。。
> 今の仕様のままでニックネーム以外のSregは返さない
> 方が良さそうです。
すみません、問題となるケースを詳しく教えて頂けま
すか？
した。
# http://openid-japan.org/ のサーバについて残念なお知らせ
が出てました。
On 2008/08/28, at 3:56, Tatsuki Sakushima wrote:
> ㈰「メンバーシップ」という表現について
>
> ソーシャルサイトでの友人関係も扱えると思うの
> で、
> メンバーシップよりはより広い概念を包括している
> のかな？
> と思いました。そうなると、RelationshipとかSocialとい
> う
> 表現のほうが適切かなと思いました。（注：主観
> 入ってます。）
> 用語決定については英語圏の人を巻き込むと良いで
> すね。
そうですね。当初は「関係認証」等とも呼んでいたの
でRelationshipも候補に挙げていましたが、mixi OpenIDのモ
デルは実際には「関係の認証」ではなく「集合への所属」の認
証だったのでドラフトではMembershipを選びました。こ
のへんは崎村さんが gen...@openid.net にpostして頂いたの
をきっかけに、ディスカッションが進めば...とか思っ
たのですが、悲しいことに反応無いですね。
ちなみにソーシャルグラフを扱うアプリケーションで
は関係というプリミティブな要素ももちろん扱います
が、大部分のケースでは「特定の集合に属しているか
否か」程度の大雑把なモデルの方が扱いやすいと私は
考えています。また企業内の情報システムで使うACL的
なものをMAMで実装する場合にも言えるのではないかと
思っています。
> ㈪「認証リクエスト」の部分
>
> MAMでは、RPオーナーが各種識別子を指定することに
> なると思いますが、
> OpenID畑から来た人が読むと、「どこでユーザーは
> OpenIDを入力するのか？」
> と思っています。この点ははっきり強調されたほう
> が良いと思いました。
なるほど。ここはMAMを使うOP/MP/RPが実現したいものに
よって変わってくることを想定して明言していません
でした。通常はRP上でMAMを適用したい情報の所有者or
管理者がグループ識別子をセットしますが、可能性と
してエンドユーザによるuser-suppliedなグループ識別子
を使う場合もあるのかなと思っています。
# RPとしてはとても使いにくいとは思いますが :-P
となるとこんな感じでしょうか。
訂正前: RPは認証したいグループ識別子からMP終点URLを
探索する。
訂正案A: RPは管理者が指定したグループ識別子からMP
終端URLを探索する。
訂正案B: RPはエンドユーザが入力、または管理者が指
定したグループ識別子からMP終端URLを探索する。
む、この場合、RPオーナーなどを指す「管理者」って
言葉が未定義でした。用語への追加が必要。
> ㈫「付録A.1」のユーザー識別子
>
> 上に関係しますが、「付録A.1」で「あるエンドユー
> ザーは自身の識別子として
> "http://www.example.com/"を用いる」とありますが、MAMでは
> これは「MP識別子」に
> なるのではないでしょうか？MAMは普通のOpenID認証と
> 違うと思いますので。
> このURLはユーザーの持ち物ではありませんね？
> OpenID2.0の仕様を読むと、
> Claimed IDは「An Identifier that the end user claims to own」とあ
> ります。
なるほど。たしかにこれはユーザの識別子とMP識別子
> 上に関係しますが、「付録A.1」で「あるエンドユー
> ザーは自身の識別子として
> "http://www.example.com/"を用いる」とありますが、MAMでは
> これは「MP識別子」に
> なるのではないでしょうか？MAMは普通のOpenID認証と
> 違うと思いますので。
> このURLはユーザーの持ち物ではありませんね？
> OpenID2.0の仕様を読むと、
> Claimed IDは「An Identifier that the end user claims to own」とあ
> ります。
が暗にぶつかっているので、例として不適切ですね。
おそらく下記のような感じにID例を書き換えると誤解
の余地が無くなりそうですね。
"http://www.example.com/" -> "http://www.example.com/foo"
"http://www.example.com/friends" -> "http://www.example.com/foo/friends"
"http://www.example.com/friends/female" -> "http://www.example.com/foo/friends/female
"
"http://www.example.com/friends/male" -> "http://www.example.com/foo/friends/male
"
"http://www.example.com/Example.Inc" -> "http://www.example.com/foo/Example.Inc
"
> ㈬その他気になった点
>
> 瑣末になりますが、2点あります：
>
> １．RPから見てMPが複数ある場合の実装はどうなるの
> だろうか？と考えました。
> ユーザーがRPが誰か判断して、その人とつながりの
> あるMPを選択するという
> ユースケースもあるのかな？と。
> （あんまりユースケースを広げすぎると仕様が複雑
> になるという弊害があるのは
> 理解しているのですが、この仕様をUSのコミュニ
> ティに出したときにどういう
> 反応がありそうか？気になりました。こっちだ
> と、みんなLinkedIn、Plaxo、
> MySpe、など普通に併用していますので。）
このへんは未定義です。MAMのXRDSでの記述について書
き入れるのを忘れていたのですが、OPのXRDSのサービス
型にMAMを追加することで、RP側でMPを最低限レコメン
ドする余地が残ると思います。あと、異なるMPのグ
ループ識別子を包括して提供するMP Aggregation serviceも
この枠組みで実現できるとおもっているので、実現可
能なシステムを付録Bで提案してあとは作り手の想像
力に任せた方が面白いかなとも思いました。
もうちょっと適切な誘導(?)方法があったら是非教えて
ください。
> ２．MAMで使う識別子がそろった場合、人の設定を勝
> 手に使えてしまうのかな？
> と思ったのですが。RPが誰か特定するのは、とても
> 難しいのですが。。。
> 今の仕様のままでニックネーム以外のSregは返さない
> 方が良さそうです。
すみません、問題となるケースを詳しく教えて頂けま
すか？
Tatsuki Sakushima
Sep 4, 2008, 2:59:02 PM9/4/08
to openid-ja
> そうですね。当初は「関係認証」等とも呼んでいたの
> でRelationshipも候補に挙げていましたが、mixi OpenIDのモ
> デルは実際には「関係の認証」ではなく「集合への所属」の認
> 証だったのでドラフトではMembershipを選びました。こ
「集合への所属の認証」という点はその通りだと思うのですが、
やはり「MPが誰で、どんな関係を扱っているのか？」で、
仕様の意味は変わってくるのかなと思いました。
＃かといって、「関係であるべき」と主張しているわけでは
ありません。一意見だと思ってください。
しかし、この仕様を海外に紹介した際に、
欧米圏の技術者の傾向として、より抽象性を求め
てくる傾向はあると思います。
> なるほど。ここはMAMを使うOP/MP/RPが実現したいものに
> よって変わってくることを想定して明言していません
> でした。
開発者にとって、識別子を指定するパターンに何がわるかわかると
良いので、それらの数が決まっているのであれば、全部書いてある
方がいいかもしれません。パターンは以下の２つかなと思いました：
１．RPが指定
２．ユーザーが指定
> # RPとしてはとても使いにくいとは思いますが :-P
仕様で、１に限定してしまうという手がないわけでは
ないと思います。ユーザーセントリック信奉者には反論
されそうですけど。
> このへんは未定義です。MAMのXRDSでの記述について書
"OPのXRDS"にすれば、「ユーザーが選ぶ」ユースケースも実現
できそうですね。
-RPが認証に使えるグループを指定。
-ユーザーは自身のOpenIDを入力して、XRDSのグループ所属リストを提示。
-RPのリストとマッチするものがあれば継続、なければRPでごめんなさい。
-マッチしたMPへユーザーをリダイレクト。あとは同じ。
OPでのMPリストのメンテが面倒そうですが。。。
> この枠組みで実現できるとおもっているので、実現可
> 能なシステムを付録Bで提案してあとは作り手の想像
> 力に任せた方が面白いかなとも思いました。
> もうちょっと適切な誘導(?)方法があったら是非教えて
> ください。
そういう意味では、IIWはいい機会だと思います。
＃今年2回目が11月にあります。
http://www.windley.com/events/iiw2008b/announcement
> すみません、問題となるケースを詳しく教えて頂けま
> すか？
例えば、誰かさんが私の友達識別子を使って、偽RPをたて、
私の友達にメールで周知します。で、このアプリにはこれこれの情報も
いるので聞かれたら許可してねとメールで伝言しておくと、
私の友達は気にせず情報提供してしまうのではないかと思いました。
普通にOpenIDを使った認証でも同じ問題が残っていますが。。。
それとわざと誰かに私の友達だけ認証を許可してもらうユースケースも
ありえますね。Mixi様だとユーザーベースが大きいので、この辺り、
セキュリティのアイデアを担保しておいた方がいいのかなと思いました。
一つの解決方法としては、MP側でどのRPが、どのグループ識別子を
確認しようとしているのか？わかる様に認証時に示すことを
仕様で義務づけるのでしょうか。
以上、よろしくお願いいたします。
追伸
サーバダウンの件につきましては、もう少しお待ちください。
申し訳ございません。
Reply all
Reply to author
Forward
0 new messages