３年前のOpenID Summit Tokyo で「最高にエモい」と好評だった OpenID Summit Tokyo のクロージング・キーノートの録画が公開されました。 本編スタートは 06:18 から。将来と希望ということから話を始め、産業革命の本質と大英帝国成立の背景を説明、そこから得られる第４次産業革命への示唆とサイバー大陸＝第八大陸の成立とアップル教皇国、フェイスブック王国、グーグル共和国、WeChat人民共和国など列強(#GAFAM)による #第八大陸分割、#DFFT による経済成長についてのEUの見解、#eID #trustservices #eIDAS の意義、そして戦わない楽な道＝ #西用 路線をとることによる植民地化と貧困への道と、 #変法 による希望のもてる将来の話をしています。 ３年前のスピーチですが、今でも全く古びていないと思います。いやむしろ、 #web3 で分

さる８月９日に、独立行政法人 情報処理推進機構（IPA)から『アイデンティティ管理技術解説』[1]という教科書のドラフト版が公開された。８月版はまだドラフトで、各方面からの指摘を受けてどんどん直してゆくたたき台だそうだ。大変な力作であり、完成版が渇望される。 すでに色々なコメントをお返ししたが、SAMLとOpenIDを比較した表5.2-1が明らかに間違っているので、この表がひとり歩きする前に、ここに指摘しておくことにしたい。 問題の表は以下のとおりである。 （出所）IPA 『アイデンティティ管理技術解説』ドラフト版（８月版） より表 5.2-1： SAML と OpenID の特徴 この表のOpenID の欄をご覧頂きたい。以下、順に間違いを指摘してゆく。 間違い1. 「一つのデジタル・アイデンティティで」 デジタル・アイデンティティの定義は、属性の集合である。OpenID 2.0 では、

（出所） https://twitter.com/Moohten/status/863126339888480256 日経新聞から、「警告を無視　起こるべくして起きたサイバー攻撃」1という記事が流れてきた。文中には以下のような記述がある。 もちろん、一義的な責任は米マイクロソフト（ＭＳ）にある。（今回の攻撃の対象となった）基本ソフト（ＯＳ）「ウィンドウズ」を販売し、長年にわたりセキュリティー上の欠陥を批判されてきたからだ。 いやいや、第一義的な責任はマイクロソフトでは無く、サポートが終了しても使い続けた組織、パッチが出ても適用しなかった組織にあるだろう。こういう無責任な責任転嫁が公衆を危険に晒しているのだ。 もういい加減、ソフトウェアの購入は、物理的財（goods）のように購入し所有しているのではなく、一定期間内の利用の権利を取得しているだけなのだということを理解したほうが良い。ソフトウェ

OpenID Foundation の Financial API WG (FAPI WG)で策定を進めている、『Financial API — Part 1: Read Only Security Profile』が、Implementer’s Draft1投票に掛ける前の最終レビュー中です。Implementer’s Draft 投票は、技術的な要素とそれに関わる知財をロックインするためのもので、Implementer’s Draftになると、実装者は自由に実装が可能になりますので、その点で重要なものです。 もしご関心がおありでしたら、ぜひWGに参加（無料）して、課題管理票 に課題をあげてください。 以下に、目次を記載しておきます。

どうやら、多くの企業の「ビッグデータ」はだだ漏れているようです。スイス・チューリヒのセキュリティ企業BinaryEdge[1] の調査の結果[2]、大量のデータがそのままインターネットにさらされているようなのです。その総量はなんと1.1ペタバイト。 同社の調査は、Fortune 500企業からベンチャーまで幅広い企業のインターネットに晒されているホストをスキャンし、公開されているMongoDB, Memchached, Elastic Search, Redis Cache などからメタデータを引き抜いてくるというものでした。（同社は、データ自体は取得していないことを明言しています。） それによると、 35,330件のRedis Cache、 39,134件のMongoDB、 118,574件のMemcached、 8,990件のElastic Search が、認証・認可無くデータを全世

ずいぶん長くかかりましたが[1]、JSON Web Signature (JWS)とJSON Web Token (JWT) がようやく Standard Track の RFC[2]になりました。それぞれ、[RFC7515]と[RFC7519]です。 ご存じない方のために申し上げますと、JWSはJSONにデジタル署名するための規格です。XML署名のJSON版ですね。JSONシリアライゼーションとCompactシリアライゼーションの2種類あり、Compactシリアライゼーションがあります。 JWTは、このCompactシリアライゼーションのJWSに、いくつかの有用なパラメータ名を導入して、ログイン情報やアクセス許可情報を伝達できるようにしたものです。主にRESTfulなシステムでの利用を想定していますが、もちろんそれ以外でも利用可能です。既に、GoogleもMicrosoftも大規模に実装

このプログラムによって、OpenID Connectを実装している事業者は、自身の実装がOpenID Connect標準仕様を満たすことを宣言することができます。このCertificationプログラムに参加することで、異なる実装間での相互運用性がより確実なものになるでしょう。 OpenID Certificationテストスイートは、デジタルアイデンティティに関わるシステム間の相互運用性を促進する目的で、スウェーデンのウメオ大学 (Umeå University) およびEUのGÉANTプロジェクトの協力により、オープンソースソフトウェアとして開発されました。 OpenID Connectは、セキュアでモバイルフレンドリーかつプライバシーにも配慮した、Identity技術のオープンスタンダードです。昨年のRSA Conference 2014での仕様確定以降、この仕様はGoogle Si

オオカミが来た：人気のオープンソースセキュリティソフトウェアでまた1つ大きな脆弱性が見つかった？！ーCNETがダメダメな件 「OpenSSLの脆弱性「Heartbleed」に続き、人気のオープンソースセキュリティソフトウェアでまた1つ大きな脆弱性が見つかった。今回、脆弱性が見つかったのはログインツールの「OAuth」と「OpenID」で、これらのツールは多数のウェブサイトと、Google、Facebook、Microsoft、LinkedInといったテクノロジ大手に使われている。」（出所：OAuthとOpenIDに深刻な脆弱性か–Facebookなど大手サイトに影響も） あのなぁ…。英語版のCNETで出てから、ZDNetとかMashableとかですぐにこの記事を叩く記事が出て、その後日本語版が何日も出なかったので、「あぁ、日本のCNETは良識があるな」と思っていたら、単にゴールデンウィーク

平均律とは、1オクターブを12の半音に均等に分ける調律法で、19世紀後半からポピュラーになってきたものです。これによって、24の調どれで弾いても同じ響きが得られるようになり、転調も自由になりましたが、反面、どの和音をとっても音が濁っていてキタナイという状況が生まれました。どのくらい汚いかをまず初音ミク演奏で体験してみましょう。それぞれ最初の1分で良いです。 平均律クラヴィーア曲集第2集9番 BWV878よりフーガ（平均律版） 平均律クラヴィーア曲集第2集9番 BWV878よりフーガ（キルンベルガーIII版） そしてもう一度： 平均律クラヴィーア曲集第2集9番 BWV878よりフーガ（平均律版） え？！ってなりませんか？平均律キタナイ。とても聞く気にならない。 でもあなたは言うかもしれません。「だって、バッハは平均律のために書いたんでしょ？平均律クラヴィーア曲集というくらいだし。」 ぶーっ。

某所でのパスワード管理が話題になっているので、私が手元で使っているパスワードを含むクレデンシャル管理に関する要求事項の目的・脅威部分をチラ見せ。ISO/IEC 29115 ベースに、ちょびっとだけ書き加えておりますです。 9.2       クレデンシャルの検証／認証 認証フェーズにおいて重要なのは、様々な手段を組み合わせることによって適切な認証レベルを獲得することである。 9.2.1            目的・脅威 クレデンシャルの検証／認証の目的は、ユーザの身元をクレデンシャルの保有の検証をもって間接的に確認し、意図したユーザのみにサービスを提供することを可能にすることである。 この状況における脅威には以下の様なものがある。

NHK News Web から、こういう記事が流れてきた。 スノーデン容疑者「個人情報収集やめさせよう」 曰く 「国家に大量の個人情報の収集をやめさせよう」と訴えました。 怪しいと思ったので、原本にあたってみた。原本はこちら。 Alternative Christmas Message: Alternative Christmas Message 2013 on 4oD at Channel4.com 思った通り、言っていなかった。彼が言っているのは、 大規模監視社会を終わらせよう。 だ。そして、その過程でプライバイシーについても語っている。 英国のジョージ・オーウェルはそうした監視社会の危険性を訴えましたが、そこで描かれているテレビやマイクなどの手段は、我々が直面しているものに比べたら如何程のものでもありません。 私たちは、どこに行こうとも追いかけてくるセンサーをポケットの中に持っている

In some of the feedback I have gotten on the openID Connect spec, the statement is made that Connect is too complicated. That OAuth 2.0 is all you need to do authentication. Many point to Identity Pro… 英語読みたくないという人のために簡単に解説すると… OAuth 2.0 の implicit flow を使って「認証」をしようとすると、とっても大きな穴が開きます。 カット＆ペーストアタックが可能だからです。 OAuth 認証？は、図１のような流れになります。 図１ OAuth 認証？の流れ 一見、問題なさそうに見えます。しかし、それはすべてのサイトが「良いサイト」ならばです。 Site_A

海外に行くと、既に REST対SOAPの決着は付いている[1]（エンタープライズでもコンシューマでも）ように見えるのだが、日本国内で話していると、まだまだ混乱しているようだ。さながら2009年ごろの状況を見るようだ。そこで、今日は RESTに関わる誤解について、幾つか書いてみたいと思う。（殴り書きだが、あんまり聞かれるのでFAQとして。なお、以下の多くは、[2] サービスステーション：RESTの詳細でより詳細に書かれている。） 誤解1. RESTはマッシュアップ用のプロトコルで、サーバ間通信には適さないのではないか？ どこからこのような誤解が来ているのか理解に苦しむ。ひょっとすると、RESTはHTTPベースということが、ブラウザとWebサーバのやり取りという風に誤って捉えられているのかもしれない。 もちろん間違いである。 ブラウザとWebサーバとの間同様、サーバからサーバへの通信にもHTT

昔から、「OpenIDは認証でOAuthは認可だ」などということが言われます。しかし、その言語の意味を取り違えている方が結構多い気がしています。「もうOpenIDなんていらね。OAuthだけでいいじゃん」というような言説がよく流れてくるのがその証拠だと思います。OAuth認証というのもその類ですね。 そこで、今日はOAuthとOpenIDの違いを考えてみたいと思います。 OpenIDは紹介状、OAuthは合鍵 まずはOpenIDの概要の復習です。「OpenIDは認証」という言葉の内容をまずは復習してみましょう。 「認証」とは大変広い言葉でいろいろな場面で使われますが、「OpenIDは認証」という使い方の時は、「OpenIDは、いま来ている人の身元を認証」（ユーザ認証）という意味です。図にすると図1のような流れになります。 この例では、有栖さんがお客としてサービス提供をしているサイトである伊