
English: 
Hi, I am Nat Sakimura, the chairman of the OpenID Foundation,
and a senior Researcher at Nomura Research Institute.
Today, I want to talk a bit
about the new identity protocol we are building:
OpenID Connect,
an identity layer on top of Oauth 2.0.
But before diving into it,
I need to define "identity",
which we often talk vaguely.
Luckily, ITU-T and ISO has defined it in the IT context for us:
it is
"Set of attributes related to an entity"
To understand this definition,
we have to understand entity identity model.
Entity is like us, human being, or machines, services,
whatever.
But we do not perceive entities directly, but indirectly through
various attributes about the entity,

Japanese: 
こんにちは。OpenID財団理事長の崎村です。
野村総合研究所の上席研究員でもあります。
今日は、現在作成中の新しい
アイデンティティ・プロトコルについてお話したいと思います。
OpenID Connect,
OAuth 2.0上に作られたアイデンティティ層です。
しかし、その詳細に入る前に、
「アイデンティティ」とは何かということを定義する必要があります。
これはしばしば曖昧に語られ混乱を生んでいますが、
幸運なことに、ITU-TとISOが情報技術の観点から定義してくれています：
それは、
「ある実体に関連する属性の集合」です。
この定義を理解するには、
実体-アイデンティティ・モデルを理解する必要があります。
実体とは、わたしたちのような人間や、機械、サービス、
その他諸々のものを指します。
しかし、私たちは実体を直接観測することは出来ず、間接的に
その実体の様々な属性を通じて観測します。

English: 
like he has blond hair, wears glasses, 6 feet 5 inches tall, etc.
and we want to express ourselves depending on who we are talking to by
controlling what set of attributes, identity, we show.
So, your identity to your friends and identity to your boss are naturally
different
so we have multiple identities
Men are said to have typically a few identities, like Work,
Husband, Father
and women have a lot more
We pick and choose which identity we use
depending on the context
The same holds for web sites.
You want to use different identities
depending on the sites you go to get better service.
That's the identity layer,
and with OpenID Connect, we have chosen to build it over
OAuth 2.0.

Japanese: 
たとえば、金髪、メガネ、身長190センチ、などです。
そして、私たちは相手に応じて、属性の集合、すなわちアイデンティティを
出し分けて、相手に見て欲しい自分を表現しています。
したがって、友人に対して出すアイデンティティと、上司に対して出すアイデンティティは
自ずと異なるのです。
というわけで、私たちはみな複数のアイデンティティを持っています。
男性は典型的には数個のアイデンティティを持っていると言われます。
仕事、夫、父親、などです。
一方で女性はもっとたくさん持っていると言われます。
その中から私たちは、状況によってどのアイデンティティを
使うかを選択しているのです。
同じ事はWebサイトにも言えます。
どのサイトに行くかによって、アイデンティティを使わけることによって
より良いサービスを受けようとします。
それが、アイデンティティ層なのです。
OpenID Connectでは、それを
OAuth 2.0 上に作ることを選択しました。

English: 
This is often called "Authentication" as well.
But you may ask
"Why not just OAuth?
Facebook does the same with OAuth do not they?
Well, not quite.
OAuth itself has no notion of identity.
OAuth is an access granting protocol,
also known as delegation.
Alice granting an access to Betty's profile data to Cindy
does not mean that Alice is Betty nor Cindy is Betty.
Unfortunately though,
many services make this mistake
and make it easy for a service
to impersonate a user.
Facebook's case is different.
They do not use OAuth for authentication as is,
, but have built an extension called signed request,
which is essentially the same as the OpenID Connect's ID_token,
except for the fact that it works only with facebook as the identity
identity provider, and the signature format is proprietary

Japanese: 
これは、「認証」と呼ばれることもしばしばです。
でもあなたは聞くかもしれません。
「何でOAuthだけでやらないの？...
...FacebookはOAuth認証してるんじゃなかったっけ？」
それは、ちょっと違います。
OAuth自体は、アイデンティティの概念を持っていません。
OAuthは、アクセス許可プロトコルです。
権限移譲と呼ばれることもあります。
シンディのプロフィールデータに対するアクセス許可をベティに対してアリスがしたところで
アリスがシンディなわけでも、ベティがシンディなわけでもありません。
しかし残念ながら、
多くのサービスはこの間違いを犯して、
他のサイトが利用者に簡単に
なりすますことを許してしまっています。
Facebookの場合は違います。
彼らはOAuthをそのまま認証に使っているわけではありません。
signed_request という拡張機能を構築して使っています。
これは、OpenID Connect の ID Token と基本的に一緒のものです。
違いは、signed_requestはFacebook以外の認証サーバを使えないのと、
署名形式が独自であるのに対して、

Japanese: 
OpenID Connect 複数の認証サーバを使うことができ、
署名にはIETFのJSON Web Signature 標準を使っていることくらいです。
要は、
Webサイトに対して、以下の様なことを提供すること：
「誰が認証をうけたのか」
「どこで、いつ、どのように認証されたのか」
「どの属性をなんの為に送ることに同意してくれたのか」
このすべてをシステム間の互換性を確保した形で行うプロトコル、
-- それが、OpenID Connect なのです。
相互運用性に富み、
単純かつモバイルに適しており、
安全で、
柔軟。
相互運用性のためには、
属性Claimを要求・回答するための標準的な方法を定義しなければなりません。
その為、標準スコープ、より細分化された
属性Claimを要求する方法、
ID Token、
及び、利用者の属性を取得したり、トークンを変換したりするための
するためのUserInfoエンドポイントを定義しました。
また、OpenID Connectはとても単純です。
JSONベースで、
RESTフレンドリーで、

English: 
while OpenID Connect works with multiple IdPs and uses IETF's
JSON Web Signature standard.
In essence,
what it does is to provide the web sites
"Who got authenticated",
"Where, When and How it was",
"What attributes he want to give to you and Why"
All of these defined in an interoperable manner
-- that is OpenID Connect.
It is Interoperable
Simple & mobile friendly,
secure
and flexible
To be interoperable,
we have to define a standard way of requesting and responding claims.
So we have defined standard scopes, a method to ask for more granular
claims,
ID Token
and UserInfo endpoint from which you can get the attributes as well as
the translated tokens.
It's also very simple.
It is JSON based,
REST friendly,

Japanese: 
最も単純な場合には、
コピペだけで対応サイトを実装することができます。
また、最初から設計要件に入っているのとOAuth 2.0の上に作ったことにより、
モバイルにも非常に適しています。
そのセキュリティモデルは、ISO/IEC 29115 保証レベル１〜４まで
カバーできるように、暗号その他の技術を用いて
設計されています。
また、非常に柔軟でもあります。
JSONベースの要求オブジェクトを使うことで、細かい粒度で要求項目を決めることが
できるので、データ最小化も容易です。
属性Claimの返却方法には、
集約、分散双方に対応しています。これらは、必要なプライバシー要件によって
使い分けることができます。
OpenID Connect は大手のアイデンティティ・プロバイダを使うだけでなく、
個人が自前のプロバイダを建てることも可能としてます。
たとえば、
あなた専用のアイデンティティ・プロバイダを、自分のスマホの上に構築することも可能です。

English: 
in simplest cases,
it's just copy and paste to implement a simple relying party
and mobile and that's friendly because that was an explicit design principle
and thanks to OAuth 2.
Its security model can scale all the way up to extremely secure,
spanning from ISO 29115 Level of Assurance 1 to 4
leveraging on crypto and other techniques.
It's also very flexible.
You can make a granular request through JSON based request object,
which makes data minimization easy.
To return the claims,
you have the choice of aggregated and distributed claims with different
privacy characteristics.
OpenID Connect not only supports large identity providers,
but you can actually have your own identity providers.
For example,
you can choose to use a dedicated identity provider on your phone.

English: 
Current status of the specs are that they are waiting for some underpinnings such
as JOSE specs and webfinger go final.
Once that is done,
we can finalize OpenID Connect and put it to the final membership vote.
In the meantime,
people are implementing current draft.
Right now,
14 solutions are performing interops encompassing
over 120 feature tests.
So, start Building OpenID
Now!

Japanese: 
標準仕様の現在の開発状況ですが、依存する他の標準、たとえば、
JOSEやWebfinger仕様が完成するのを待っている状態です。
それが出来た暁には、
OpenID Connect をすぐに全メンバー投票にかけて、標準として承認することができます。
その間、
人々は、現在のドラフトの実装を始めています。
ちょうど今、
14のソリューションが120以上の項目をテストする
相互接続性テストを実施中です。
OpenID Connect いつやるの？
今でしょ！
