Relying Party Best Practices　ななめよみ

Relying Party(OpenID認証利用サイト)のベストプラクティス、というタイトルのエントリが
http://wiki.openid.net/というところで公開されていました。


目次はこんな感じ。

1. Basic
　　　1. Site allows user to authenticate using an OpenID identifier
　　　2. Site allows creation of new user account by simply signing in using an OpenID identifier
　　　3. One Site Account per OpenID, unless the site enables manual account selection
　　　4. Site unambiguously indicates authenticated users
　　　5. Treat extensions as optional, not mandatory
　　　6. Clearly inform the user if their OpenID will be published
2. Would Be Nice
　　　1. OpenID-authenticated users have full access to all provided services
　　　2. Allow users to upgrade from a local username/password account to an OpenID account
　　　3. Allow users to change the OpenID Identifier associated with their account
3. Brilliant
　　　1. Provide Lost Identifier functionality to switch to a new identifier without access to the old one
　　　2. Provide the ability to merge accounts
　　　3. Many-to-one relationship between Identity URLs and user accounts
　　　4. Don't require users to choose locally-unique usernames
　　　5. Allow, but do not require, users to attach a handle or name to their identity
　　　6. Store primary OpenID in a cookie and check_immediate at next session

Relying Party Best Practices

正確な和訳はとてもできない頭なので、目次と説明文をあわせて雰囲気で読んでみた"感想"を書いていく。


本題に入る前にまずは用語の整理を。わかってる人はここ飛ばすよねJKなところ。

ユーザがRelying Partyサイト上でログインをするために、(一般的なIDとPasswordによるログインではなく)
自身の持つOpenIDを指定してOpenID Providerサイトに移動し、Providerサイト上で
(ここでは一般的にはID/Password認証が多い)認証を行う。ここでのログインが認められた場合に、その
認証OKな結果がRelying Partyサイトに通知され、自サイトでの認証行為相当が行われた、とみなすこと

  • Relying Party

OpenIDログインができるサイト。例えばiKnow(http://www.iknow.co.jp/)とか。

Relying Partyサイトで「○○でログインする」ボタンが付いているような
「OpenIDを利用した時に認証を行ってくれる」ID提供サイト。
例えばmixi,yahoo,google,livedoor とかのこと。


では雰囲気読み開始。

1. Basic

1. 基本

1. Site allows user to authenticate using an OpenID identifier

（当たり前）Relying PartyはOpenID認証ができるよ

2. Site allows creation of new user account by simply signing in using an OpenID identifier

Relying Partyサイト側のユーザアカウントを持っていないユーザが
OpenID認証結果を利用したら、アカウントの新規作成をするようにして。
その際、SREGやAXを利用した登録支援ができればいいね。

3. One Site Account per OpenID, unless the site enables manual account selection

基本的には一つのOpenIDは一つのRelying Party側のアカウントと紐付けるべきだぜ、
但しRelying Partyサイト上でアカウント管理機能があれば話は別だけどな。

4. Site unambiguously indicates authenticated users

Relying Partyサイトは、OpenID認証されたユーザID(※)を明確にサイト上で示すべき。
※(Verifiedされた)Claimed Identifierのことだろう

5. Treat extensions as optional, not mandatory

拡張は扱える(例えばSREGなど)べし
またProvider側がSREG対応していない場合にも(UI、UX的に)適切な処理をして。

6. Clearly inform the user if their OpenID will be published

Relying PartyサイトによってユーザのOpenIDが公表されるかどうかについては、
Relying Partyサイトは明確にユーザに知らせるべきでしょ


※正直、阿呆すぎてでこの意味がわからなかった。
RPがユーザの利用しているOpenID(Claimed Identifier)を
表に出すかどうかは基本的にRPの勝手だから、
そのことをユーザにわからせろよ、てこと？かな。

2. Would Be Nice

2.いい感じ

1. OpenID-authenticated users have full access to all provided services

OpenID認証を利用するユーザと、Relying PartyサイトでのUsername/Password認証を利用していた
ユーザの間で、提供できるサービスに差がないようにするのが望ましいなぁ

2. Allow users to upgrade from a local username/password account to an OpenID account

Relying Partyサイトで元々Username/Password認証を利用していたユーザを
OpenID認証でもログインできるようにする(アップグレードできる)のがいいよ

3. Allow users to change the OpenID Identifier associated with their account

Relying Partyサイト上のアカウントに紐づいているOpenIDをユーザが変更・管理できること


※2.は全体的に既存のWebサイトがOpenID対応する場合のプラクティスですね

3. Brilliant

3. ちょーちょーちょーいい感じ。

1. Provide Lost Identifier functionality to switch to a new identifier without access to the old one

(例えばユーザが利用していたOpenID Providerが無効になったなど)古いOpenIDと紐づいた状態の
Relying Party上のアカウントに対して新しいOpenIDにユーザが紐付けることができる機能を提供すること
※もしRelying PartyがユーザのEmailアドレスを知っているなら「パスワード忘れた場合は」機能と
似た機能を実装すればいいかもしれない、とのこと。

2. Provide the ability to merge accounts

一人のユーザが持つRelying Partyサイト上の複数のアカウントをマージできること
OpenID認証を提供することで、ユーザが複数のID作成をしてしまうケースは増えてしまう
だろうから、「人に紐づく単位でIDを束ねる」機能は必要になるはず。


※どのOpenID ProviderでこのRelying Partyサイトを利用したか忘れてしまう問題って、あると思います。

3. Many-to-one relationship between Identity URLs and user accounts

ユーザが利用するOpenID((Verified)Claimed Identifier)とRelying Partyサイト
のIDが"他対１"の関係であること


※上のマージ機能を提案している時点で当たり前な気がするけど。

4. Don't require users to choose locally-unique usernames

Relying Partyサイト上でユーザを一意にするための名前は、ユーザに要求するのではなく
OpenID識別子(Verified Claimed Identifier)を利用すること。
（ユーザにとっても混乱の元になるでしょ？）


※これも基本、な気が。。いわゆるOpenID再利用問題にも絡む問題となるし。

5. Allow, but do not require, users to attach a handle or name to their identity

(でも)ユーザが任意のハンドルネームを作成する機能があれば好ましいかもしれません
一意性という観点では、ハンドルネームはユニークでなくても構いません
ブログのコメントユーザ名などで好まれるでしょう。とのこと

6. Store primary OpenID in a cookie and check_immediate at next session

OpenID認証を簡略にするため、そのユーザにとってプライマリなOpenID情報をもつ
Relying PartyサイトのCookieをセットするようにし、check_immediateを実行するべし

感想まとめ

断然リアリティがあり素晴らしいです。