エンタープライズ内部だと、トラストサークルを考えなくて良い分、実はOpenIDの方が向いていて、インターネットだと誰でも相手が良いわけではないので、SAMLの方が向いているかも、という議論もあることはあるしね。 #ki10 2分前 webから 3人がリツイート

• 返信
• リツイート

_nat

崎村夏彦 (=nat)

@_nat つまりOpenIDをSAMLなみのレベルに上げる必要がある、ということすか。

全国民に識別番号を割り当てることで、行政サービスの品質と効率の向上を目指す「国民ID」制度。7月11日投票の参議院議員選挙の争点に浮上した消費税率引き上げでも、国民ID制度は、その実現のための重要基盤に位置づけられている。低所得者ほど税負担率が高まる“逆進性”を緩和する「給付付き税額控除」を導入するには、所得の正確な把握のために個人識別番号が不可欠だからである。

うーむ。。。。。

3.1. OpenID 2.0 Profile

 　OpenID 2.0 Profile [4] は、OpenID Authentication 2.0 仕様を適用するためのプロファイルである。OMB M-04-04 が定める4 段階の保証レベル（LOA：Levels of Identity Assurance）のうち、レベル1 に対応している。
 　本プロファイルの規定では、IdP がRP に提供するユーザ識別子としてPPID（Private Personal Identifier：IdP とRP の組ごとに異なる「仮名識別子」）の使用を必須とすることで、RP 間での識別子のコリレーション（名寄せ）を防止している。なお、このRP からIdP へのPPID の使用の指定は、OpenID 拡張仕様のひとつであるPAPE（Provider Authentication Policy Extension）の認証ポリシーによって定義される。
 　また本プロファイルの規定では、RP は事前に認定されたIdP のリストを自身で管理し、ユーザにOpenID 識別子を直接入力させるかわりに、そのリストの中からユーザに選択させる方法のみが許可されている。これは、いわゆる「ディレクテッド・アイデンティティ」と「IdP ホワイトリスト」を組み合わせたパターンである。
 　その他、OpenID 認証に関するすべての通信をSSL/TLS にすることや、「IdP ホワイトリスト」をICAM が管理し、RP がこのホワイトリストを適宜参照することなどが定められている。

Open Identity Solutions for Open Government

Speaking of, from a technical perspective — I’m really just talking about repackaging OpenID as a profile of OAuth WRAP (credit: Recordon). It would provide relying parties with profile data, relationships, access to content, and activity streams — based on Recordon’s anatomy of connect.

OAuthにくらべてアプリケーション側もユーザ側も作業を簡略化できるxAuthですが、当然デメリットがあります。OAuthの利点の一つ、ユーザがアプリケーションにパスワードを預けなくても良いという点が完全に失われます。xAuthでは一度Access Tokenを取得してしまえばそれ以降パスワードは使用しませんが、アプリケーションがパスワードをちゃんと破棄したかどうかはユーザにはわかりません。もしかしたらこっそりパスワードを保存していて、裏でこそこそと悪さをしてしまうかもしれないのです。つまり、Basic認証によるAPI利用の欠点（のひとつ）をxAuth認証も抱えているわけです。（まあ、認証したらすぐにパスワードを変えちゃうってのもアリですが、Twitterのパスワード変更は色々と面倒なので…）

The only problem is that Yahoo quietly pushed through an extension to OAuth called the OAuth Session Extension. This was all done publicly but it involves some major changes to OAuth token management, which is the exact thing that has been hardest for people to understand about OAuth in the first place.

TOC

5.1.2.2.  Error Responses

If a request is malformed or contains invalid arguments, the server MUST send a response with a status code of 400. The response body MUST be a Key-Value Form (Key-Value Form Encoding) message with the following fields:

 

• ns

  As specified in Section 5.1.2 (Direct Response).

• error

  Value: A human-readable message indicating the cause of the error.

• contact

  Value: (optional) Contact address for the administrator of the sever. The contact address may take any form, as it is intended to be displayed to a person.

• reference

  Value: (optional) A reference token, such as a support ticket number or a URL to a news blog, etc.

The OP MAY add additional fields to this response.

リクエストが正しく構成されていないとか不正なパラメータがあったら、サーバー(OP)はHTTP　400をかえす。
BodyにはKey-Value　Form Endocingで以下のフィールド入れたメッセージとする。
- ns
- error
- contact
- reference
追加でフィールドを入れてもよい。

4.1.1.  Key-Value Form Encoding

A message in Key-Value form is a sequence of lines. Each line begins with a key, followed by a colon, and the value associated with the key. The line is terminated by a single newline (UCS codepoint 10, "\n"). A key or value MUST NOT contain a newline and a key also MUST NOT contain a colon.

Additional characters, including whitespace, MUST NOT be added before or after the colon or newline. The message MUST be encoded in UTF-8 to produce a byte string.

Key-Value Form encoding is used for signature calculation and for direct responses (Direct Response) to Relying Parties.

- 行単位でKey-Valueセット
- {{キー名}}:{{値}}
- 最後に改行（UCSコードポイント10 = \n)
- 不要なホワイトスペース使わない
- 改行コード使わない
- {{キー名}}にはコロン使わない