Agenda

• Overview of OpenID Authentication 2.0 ( OpenID 認証 2.0の概要 )
• Three types of Discovery (３つのディスカバリ)
• XRI and i-name (XRI と i-name)
• Problems of OpenID (OpenID の問題点)
• Future of OpenID (OpenID のこれから)

Terminology 1

Identifier

URI or XRI

URI または XRI

User-Agent

The browser you always used (c.f. IE, Firefox, Safari, Opera...).

あなたがいつも使っているブラウザ

Relying Party (RP)

Web services depends on OpenID Authentication.

OpenID 認証を使っているウェブサービス

Terminology 2

OpenID Provider (OP)

OpenID authentication server managing OP-Local Identifier

OP-Local Identifier を管理している OpenID 認証サーバー

OP EndPoint URL

The URL on OP receiving protocol messages.

プロトコルメッセージを受信する OP 上の URL

OP Identifier

The Identifier specifying OP (c.f. yahoo.com, myopenid.com)

OP を識別する識別子

Terminology 3

Claimed Identifier

The Identifier that end user claimed to own identifier. (c.f. =zigorou, zigorou.myopenid.com)

利用者が自分の識別子であると主張する識別子)

User-Supplied Identifier

Claimed Identifier or OP Identifier. The Identifier actually posted by End User.

Claimed Identifier あるいは OP Identifier。実際に利用者によって送信される識別子。

Terminology 4

OP-Local Identifier

The Identifier provided by OP for End User. This Identifier is locally used, therefore End User may not enable to control it.

(利用者の為に OP によって提供される識別子。この識別子は局所的に使われるので、利用者はその識別子を制御出来ない場合がある。)

Senario Example 1

1. End User posts their User-Supplied Identifier using login form on the RP.

   利用者は自らの User-Supplied Identifier を RP 上にあるログインフォームで送信します。

   On this example, End User posts "zigorou.example.org" as their Identifier.

   この例では、利用者は "zigorou.art-code.org" を Identifier として使うものとします。

2. The RP discoverys informaction related User-Supplied Identifier like, OP EndPoint URL, OP-Local Identifier if necessary, from User-Supplied Identifier.

   RP は User-Supplied Identifier からそれに関連する情報である、OP EndPoint URL、必要であれば OP-Local Identifier を見つけます

   On this example, discovered "http://openid.example.com/server" as OP EndPoint URL, "http://example.com/user/zigorou" as OP-Local Identifier.

   この例では、"http://openid.example.com/server" を OP EndPoint URL、"http://example.com/user/zigorou" を OP-Local Identifier とします。

Senario Example 2

3. If the RP did'nt has an association handle between itself and OP of End User, then the RP sends requests called "associate" to OP EndPoint URL.

   RP が OP との間のアソシエーションハンドルを持っていない場合は、RP は "associate" と呼ばれるリクエストを OP EndPoint URL に対して送ります

4. The RP sets up url with the value called "checkid_setup" or "checkid_immediate" and sends response with "Location" header, has its url as value, to End User.

   RP は "checkid_setup" または "checkid_immediate" と呼ばれる値を含んだ URL を準備し、そのURLを Location ヘッダに含んだレスポンスを利用者に対して送ります。

Senario Example 3

5. After the OP received "checkid_*" requests, the OP helps End User, for example user interface, navigation, to verify Claimed Identifier ( or OP-Local Identifier ).

   OP は "checkid_*" なリクエストを受信した後に、Claimed Identifier ( あるいは OP-Local Identifier) の検証を行う為にユーザーインターフェースを表示したり、ナビゲーションを用意すると言った手助けを利用者に対して行います。

6. The OP verify End User's Claimed Idendifier by some ways like a password authentication, and then the OP redirect with the results to the URL on RP called "openid.return_to" preliminarily specified by RP

   OP は何らかの方法、例えばパスワード認証、によって利用者の Claimed Identifier の検証を終えたら、その結果を予め RP によって指定された "openid.return_to" と呼ばれるキーで指定された RP 上の URL に対して利用者の UA をリダイレクトさせます。

Identifier

• http://zigorou.myopenid.com/ (Absolute URI)
• zigorou.myopenid.com (Authority part of URI)
• claimid.com/zigorou (No scheme URI)
• xri://=zigorou (Absolute XRI)
• =zigorou (No scheme XRI)

Form

• The input form element's name attribute value should be "openid_identifier". Because the browser would fill your OpenID Identifier by same name attribute's value.

  input フォーム要素の name 属性値は "openid_identifier" であるべきです。 何故なら同じ name 属性値 にする事によってブラウザは OpenID Identifier を補完するからです。

• Like example, the input form element's background would be used OpenID logo.

  例のように、input フォーム要素の背景に OpenID のロゴを用いると良いでしょう。

Discovery

Direct and Indirect Communication

Direct Communication

The RP tranfers messages to OP directly using http "POST" method.

RP は OP に対して直接メッセージを http の "POST" メソッドを使って送信します。

Indirect Communication

The RP transfers messages to OP through User-Agent requested redirection using http "GET" method.

RP は OP に対してリダイレクト要求された User-Agent を介して、http の "GET" メソッドを使ってメッセージを送信します。

Data Format

use strict;
use warnings;
use URI;

my $openid_ns = URI->new("http://specs.openid.net/auth/2.0");
my $end_point = URI->new("http://openid.example.com/server");
my $request = $end_point->clone;
$request->query_form({
    'openid.mode' => 'associate',
    'openid.ns' => $openid_ns,
});

print $request->query;
# openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.mode=associate
        

4 Request Modes

assosiate

The mode exchanging shared secret between RP and OP

RP - OP 間で共有鍵の交換を行うモードです。

checkid_setup/checkid_immediate

The mode requesting authentication through User-Agent

User-Agent を介して認証要求を行うモードです。

check_authentication

The mode verifying signature from RP to OP using Direct Communication.

RP から OP に対して Direct Communication によって署名の検証を行うモードです。

Association 1

use strict;
use warnings;
use Crypt::DH;
use Text::SimpleTable;

sub create_dh {
  my $dh = Crypt::DH->new( p => 8995127215884267541995034125870655, g => 2 );
  $dh->generate_keys;
  $dh;
}

my $rp_dh = create_dh();
my $op_dh = create_dh();

my $table = Text::SimpleTable->new([20 => 'item'], [36 => 'RP'], [36 => 'OP']);
$table->row('pub', $rp_dh->pub_key, $op_dh->pub_key);
$table->row('pri', $rp_dh->priv_key, $op_dh->priv_key);
$table->row('shared sec', $rp_dh->compute_secret($op_dh->pub_key), $op_dh->compute_secret($rp_dh->pub_key));

print $table->draw;
        

Association 2

.----------------------+--------------------------------------+--------------------------------------.
| item                 | RP                                   | OP                                   |
+----------------------+--------------------------------------+--------------------------------------+
| pub                  | 2467835628736959010041520883499008   | 753006574613379789517619654033408    |
| pri                  | 1020569182109152379992026171549303   | 3902597265081260507940401601978883   |
| shared sec           | 818269593420807859506109126541312    | 818269593420807859506109126541312    |
'----------------------+--------------------------------------+--------------------------------------'
        

checkid_(setup|immediate) modes

checkid_setup

Requesting authentication to OP with UI transition. End User would be authenticated by OP.

画面遷移のある認証要求です。利用者は OP によって認証されます。

checkid_immediate

If End User permits to return authentication result to this RP and has been log in, RP would retrieve authentication result immediatelly. AJAX style (using iframe) is used on this mode. So there is no UI transition.

利用者が認証結果を返す事を許可していてログイン済みならば、RP は認証結果を直ちに取得出来ます。このモードは (iframeを使った) AJAX スタイルで使われます。つまり画面遷移がありません。

The order of discovery

XRDS based discovery 1

XRDS based discovery 2

HXRI               = proxy-resolver "/" QXRI
proxy-resolver     = ( "http://" / "https://" ) proxy-reg-name
proxy-reg-name     = "xri." ireg-name
QXRI               = xri-hier-part [ "?" i-query ]

XRDS based discovery 3

#!/usr/bin/perl

use strict;
use warnings;

use URI;
use LWP::UserAgent;
use HTTP::Request;

my $resolver = URI->new('http://xri.net/');
my $qxri = $ARGV[0];

my $hxri = $resolver->clone;
$hxri->path($qxri);
$hxri->query_form( _xrd_r => 'application/xrds+xml' );

my $lwp = LWP::UserAgent->new;
my $req = HTTP::Request->new(GET => $hxri);
$req->header('Accept' => 'application/xrds+xml');

my $res = $lwp->request($req);

print $res->content if ($res->is_success);
        

XRDS based discovery 4

#!/usr/bin/perl

use strict;
use warnings;

use Data::Dump qw(dump);
use XRI::Resolution::Lite;
use XML::LibXML::XPathContext;

my $r = XRI::Resolution::Lite->new;
my $xrds = $r->resolve('=zigorou');

my $xpc = XML::LibXML::XPathContext->new($xrds);
$xpc->registerNs('xri', 'xri://$xrd*($v*2.0)');

my @uri = $xpc->findnodes(q|//xri:Type[text()="http://openid.net/signon/1.0"]/ancestor::xri:Service/xri:URI|);

print dump(map { $_->textContent() } @uri);

priority attribute order

1. The application should select 'Service' element with the lowest numeric value of priority attribute value.

   アプリケーションは Service 要素の attribute 属性の値として最も小さな数値を持つ物を選ぶべきです。

2. If an element has no priority attribute, the application should treat lowest priority value.

   priority 属性を持たない場合は最も低い優先度として扱うべきです。

Yadis based discovery

HTML based discovery

<link rel="openid2.provider openid.server" 
      href="http://openid.example.com/server" />
<link rel="openid2.local_id openid.delegate" 
      href="http://example.com/user/zigorou" />

Parse html using Perl

use strict;
use warnings;
use Data::Dump qw(dump);
use URI;
use LWP::UserAgent;
use HTML::TreeBuilder::XPath;

die unless (@ARGV > 0);

my $claimed_id = URI->new($ARGV[0]);
my $ua = LWP::UserAgent->new;
my $res = $ua->get($claimed_id);

die unless ($res->is_success);

my $tree = HTML::TreeBuilder::XPath->new_from_content($res->content);
my @openid = qw(server delegate);
my @openid2 = qw(provider local_id);
my %result;

$result{$_} = $tree->findvalue(sprintf('//link[@rel="openid.%s"]/@href', $_))->value for (@openid);
$result{$_} = $tree->findvalue(sprintf('//link[@rel="openid2.%s"]/@href', $_))->value for (@openid2);

print dump(%result);

5 reasons I won't be getting on the open id train

1. 99% of implementations are naive
2. OpenID just doesn’t work for the mobile web
3. OpenID assumes the internet is full of good-natured human beings
4. N OpenIDs to rule them all!
5. It’s less user friendly

1. 99% of implementations are naive

2. OpenID just doesn’t work for the mobile web

3. OpenID assumes the internet is full of good-natured human beings

4. N OpenIDs to rule them all!

5. It's less user friendly

ID Recycle

Using Yadis discovery

Contact Service

Future of OpenID

1. You will know about someone from one Identifier
2. You will contact to someone from one Identifier
3. Your friendship relation will be existed on the WEB
4. Using reputation?