セッション「デジタルアイデンティティはどこに向かうのか」の冒頭でお話したわたしの資料を公開します。 よろしくご査収ください。 0717_MyData_デジタルアイデンティティ
![[資料掲載] MyData Japan カンファレンス2024でのわたしの資料「デジタルアイデンティティはどこに向かうのか」を公開します](https://cdn-ak-scissors.b.st-hatena.com/image/square/40b00027a45f5976f844127424303aca3d29ddbc/height=288;version=1;width=512/https%3A%2F%2Fi0.wp.com%2Fwww.sakimura.org%2Fwp-content%2Fuploads%2F2024%2F07%2F0717_MyData_Where_DI.jpg%3Ffit%3D1200%252C675%26ssl%3D1)
[資料掲載] MyData Japan カンファレンス2024でのわたしの資料「デジタルアイデンティティはどこに向かうのか」を公開します
セッション「デジタルアイデンティティはどこに向かうのか」の冒頭でお話したわたしの資料を公開します。 よろしくご査収ください。 0717_MyData_デジタルアイデンティティ
「なんでアクセストークンがいるの？パスワードを保存すれば良いのではないの？」というパワーワードを聞いたので説明してみる
ID本の読者の一人から、「なんでアクセストークンがいるの？パスワードを保存すれば良いのではないの？」というパワーワードを聞いた。そうか、そういえば、そういうベーシックなことを説明していなかったな。というわけで、改定の機会があったら加筆するとして、とりあえずブログにしておきます。 OAuthと２つのトークン OAuthの登場者には、 保護対象リソース (Protected Resource)：アクセス制御がされるべきリソース リソース管理者 (Resource Owner) ：保護対象リソースに対するアクセスを決定することができる人または組織 認可サーバ (Authorization Server)：リソース管理者の指示に従って、クライアントにトークン（切符）を発行するソフトウェア クライアント (Client)：リソース管理者の許可のもとに保護対象リソースにアクセスして何らかの処理を行うソ
「Chrome Tech Talk Night #16 〜 パスキー」まとめ
2024 年 6 月 14 日、Google 渋谷オフィスにて Chrome Tech Talk Night #16 〜 パスキー が開催されました。 CTTN #16 は、開発者のみなさんがパスキーの基本について学び、よくある疑問を解決できることを目指したイベントです。 FIDO Alliance メンバー企業でアクティブに仕様策定に参加しているエキスパートの皆様がご登壇されました。 資料はこちらに公開されています：Chrome Tech Talk Night #16 パスキー 以下はClaude Sonnet 3.5 によるまとめとNotta.ai によるまとめをもとに若干手を入れたものです。なお、私はこの分野は素人なので、間違いがあると思うので、その場合はご指摘いただければ幸いです。 Chromeテックトーク16 – パスキーについて #passkeys_jp 1. イントロダクショ
デジタル庁認証アプリ FIRST IMPRESSION まとめ
昨夜(6月21日）午後11時より、YouTube Live で「デジタル庁認証アプリ FIRST IMPRESSION」と題して配信を行いました。デジタル庁が同日発表したデジタル認証アプリについて、一緒にドキュメントを読んで、その内容や課題などを洗い出していきましょうという企画です。夕方にゆるい感じでアナウンスして、トークデッキの準備も間に合わず見切りで始めたにも関わらず、デジタル庁の幹部の方なども含めて、最大94名の方が同時アクセスしていただきました。ご参加いただいた方々に深く御礼申し上げます。アーカイブは以下から見ることができます。YouTubeに遷移してみること推奨です。チャットに多くの情報がありますので。以下、AI1によるまとめと、それに書き加えた覚えている限りのメモです。そのうち見返して追記するかも知れません。 しかし、こうして見返してみると、署名の話を飛ばしてしまいましたね。こ
プライバシーを考えるなら、データの種類よりその行為の影響を考えたほうが良い
これはあちこちで話しているので「聞いたことあるよ」という方も多いかと思いますが…。 現在、パーソナルデータに関する検討会[1]というのが内閣官房で行われています。基本は、「どうしたら個人情報をもっと利活用できるようになるか」ということを検討するのがミッションで、安倍政権の第三の矢の一翼を担うものです。公開会議なので、だれでも傍聴できるのですが、あっという間に定員に達してしまうためなかなか取れないプラチナチケット化している会議でもあります。 そこで検討されていることに「（仮称）準個人情報」だとか「（仮称）個人特定性軽減データ」というのがあります。定義については、この検討会の下で開催されている技術ワーキングの中間報告書[2]（←非常な労作で、必読）を参照してください。ざっくり言うと、「準個人情報」が、「個人が特定されていない情報であっても、個人が特定されるおそれのある情報」、「個人特定性軽減デ
「最高にエモい」と好評だったOpenID Summit Tokyoクロージング・キーノート 「No ID, No DX」の録画が一般公開されました
３年前のOpenID Summit Tokyo で「最高にエモい」と好評だった OpenID Summit Tokyo のクロージング・キーノートの録画が公開されました。 本編スタートは 06:18 から。将来と希望ということから話を始め、産業革命の本質と大英帝国成立の背景を説明、そこから得られる第４次産業革命への示唆とサイバー大陸＝第八大陸の成立とアップル教皇国、フェイスブック王国、グーグル共和国、WeChat人民共和国など列強(#GAFAM)による #第八大陸分割、#DFFT による経済成長についてのEUの見解、#eID #trustservices #eIDAS の意義、そして戦わない楽な道＝ #西用 路線をとることによる植民地化と貧困への道と、 #変法 による希望のもてる将来の話をしています。 ３年前のスピーチですが、今でも全く古びていないと思います。いやむしろ、 #web3 で分
単なる 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
MacOS XとiOSのXARA脆弱性について
今日（６月１８日）午後、GigaZineで「iOSとOS XでiCloud・メール・ブラウザ保存のパスワードが盗まれる脆弱性が発覚、Appleは半年以上も黙殺」1というセンセーショナルな記事が出ました。まぁ、Webメディアだからしょうがないかという感じではありますが、記事を読んだだけでは何のことやらさっぱりなので、読みましたよ、元の論文。 その論文は、これです。 Xing, Bai, Li, Wang, Chen, Liao: “Unauthorized Cross-App Resource Access on MAC OS X and iOS” 2 まずは、著者たちに拍手をしましょう。 その上で： 著者たちが、初めて発見したと主張するゼロデイ攻撃は以下の４つ、細かくは５つに分類されます。 Password Stealing (Keychainのアクセス・コントロール脆弱性)[MacOS
「番号」設計のあるべき姿 〜 年金番号漏洩事件によせて
年金番号漏洩事件では、「漏洩した番号は全て変更する」のだそうです[1]。個人的には「あーあ」という感じでありんす。昨日の記事[2]でも書いたとおり、適切に運用していれば、番号自体の漏洩は大したリスクではなく、一緒に漏れた住所氏名他が変えられない以上、年金番号だけ変えてもあまり意味が無いからです。 逆に、設計の古い年金番号は、変えるとなると、連動して変えなければいけないところがあった場合にうまく変わらないことが想定され、そのことがかえって被害を産む恐れもあります。 「番号」（本当は識別子と呼ぶべきですが、ここでは便宜的に「番号」と呼びます）の設計というのは、想定される利用形態によって様々な考慮点があります。したがって、『「番号」設計のあるべき姿』はある意味ケースバイケースということにはなります。しかし、一方では、最低限満たすべき要件というものもあるのですね。 という訳で、ちょっとリストアップ
「番号」は漏れると危ないのか？
さて、マイナンバー対応バブル真っ盛りの夏を迎えつつありますが、皆さんいかがお過ごしでしょうか？ 折しも年金番号が盛大に漏れて1、マイナンバーへの影響もあるのではないかとなども言われておりますが、そもそも「番号」が漏れることを「住所・氏名・生年月日」などの各種個人情報以上に大騒ぎするのには私は違和感があります。それは、こと漏洩に関して言うと、プライバシーインパクトは「番号」＜「住所・氏名・生年月日」＜＜「付随する情報」だからです。 以下、簡単化のために「番号」＜「住所・氏名・生年月日」に焦点を絞ります。 1. なりすましによる被害 「番号」それ自体は、その本人のデータを他の人のデータから区別するという能力しか無いはずです。米国のSSNなどは、誤った理解から番号自体を本人確認に使ってしまったりしてなりすまし事故を盛大に起こしております2が、日本のマイナンバーや年金番号はそんなことはしていないは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
