デジタル庁認証アプリ FIRST IMPRESSION まとめ
昨夜(6月21日）午後11時より、YouTube Live で「デジタル庁認証アプリ FIRST IMPRESSION」と題して配信を行いました。デジタル庁が同日発表したデジタル認証アプリについて、一緒にドキュメントを読んで、その内容や課題などを洗い出していきましょうという企画です。夕方にゆるい感じでアナウンスして、トークデッキの準備も間に合わず見切りで始めたにも関わらず、デジタル庁の幹部の方なども含めて、最大94名の方が同時アクセスしていただきました。ご参加いただいた方々に深く御礼申し上げます。アーカイブは以下から見ることができます。YouTubeに遷移してみること推奨です。チャットに多くの情報がありますので。以下、AI1によるまとめと、それに書き加えた覚えている限りのメモです。そのうち見返して追記するかも知れません。 しかし、こうして見返してみると、署名の話を飛ばしてしまいましたね。こ
JSON Web Signature (JWS) の標準化がIETFで始まっています
JSON Web Signature という、JSON に署名をつけるための標準化が、IETFのJOSE Working Group で始まっています[1]。 初期ドラフトは http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-00 私の名前も出ていますが、これは、 OpenID Foundation の AB/C Working Group で検討していたものをIETFに持ち込んだためです[2]。 @ritou さんが、「OAuth 2.0時代の署名つきリクエストとは」というエントリで触れられていますが、Facebook の signed_request によく似ています。 大きな違いは、signed_request が 署名 . 本文 の形式になっているのに対して、JWSでは、 ヘッダ . 本文 . 署名 になって
非技術者のためのOAuth認証(?)とOpenIDの違い入門【2023年版】
昔から、「OpenIDは認証でOAuthは認可だ」などということが言われます。しかし、その言語の意味を取り違えている方が結構多い気がしています。「もうOpenIDなんていらね。OAuthだけでいいじゃん」というような言説がよく流れてくるのがその証拠だと思います。OAuth認証というのもその類ですね。 そこで、今日はOAuthとOpenIDの違いを考えてみたいと思います。 OpenIDは紹介状、OAuthは合鍵 まずはOpenIDの概要の復習です。「OpenIDは認証」という言葉の内容をまずは復習してみましょう。 「認証」とは大変広い言葉でいろいろな場面で使われますが、「OpenIDは認証」という使い方の時は、「OpenIDは、いま来ている人の身元を認証」（ユーザ認証）という意味です。図にすると図1のような流れになります。 この例では、有栖さんがお客としてサービス提供をしているサイトである伊
単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる
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
.Nat Zone : 原口５原則とOpenID by Nat - .Nat Zone
「番号に関する原口５原則」というものが発表されている。 原則１ 国民の権利を守るためのであること 社会保障給付や所々の行政サービスの提供を適切に受ける国民の権利を守るための番号であり、重複なく、もれなく、正確かつ安全に付番を行う 原則２ 自らの情報を不正に利用・ストックされず、確認・修正が可能な、自己情報をコントロール出来る仕組みであること 自らの情報が不正に利用・ストックされることなく、また自らの情報にアクセスし、内容の確認・修正ができる（自己情報コントロール権） 原則３ 利用される範囲が明確な番号で、プライバシー保護が徹底された仕組みであること 自らの情報についてどのような行政機関がどのような目的で利用するのか明確な制度とするとともに、最新の暗号化技術により情報漏えい防止に万全を期し、分野をまたがる情報の名寄せを防ぐ。 原則４ 費用が最小で、確実かつ効率的な仕組みであること 既存インフ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
