-
- いいね！4
Kaoru Maeda 前田 薫
@mad_p
novさん: 再掲: FAL: FederationにおけるAssertion/Artifactの利用形態に関する要件。Lv1: F/B-ch共にAssertionへの署名が必要。Lv2: ～に加えてF-chを利用する場合はAssertionの暗号化 #idcon
2016-11-01 19:53:47
Kaoru Maeda 前田 薫
@mad_p
novさん: 再掲: Lv3: さらにB-chでも暗号化、Lv4: さらにHolder-of-Key Assertionの利用が必須 #idcon
2016-11-01 19:54:19
Kaoru Maeda 前田 薫
@mad_p
novさん: Front channel: implicitフローのように、UserAgentに直接行く。Back channel: Assertion ReferenceをRPに渡すと、RPがCSPからAssertionをもらう #idcon
2016-11-01 19:55:06
Kaoru Maeda 前田 薫
@mad_p
novさん: Holder-of-Key Assertionとは: OAuthのpopではclientがkeyを持っているが、ここではsubscriberが鍵の保持者 #idcon
2016-11-01 19:56:01
Kaoru Maeda 前田 薫
@mad_p
novさん: F-chの例: Subscriber: pubkeyをCSPに送ってAssertionをもらう。RPにassertionとproof-of-possessionを送る #idcon
2016-11-01 19:57:30
Kaoru Maeda 前田 薫
@mad_p
novさん: 疑問: そもそもOIDC/OAuthのImplicit/Code Flowにおいて、AuthR ResponseにProof-of-Possessionを付与する仕様なんてあったっけ? #idcon
2016-11-01 19:58:34
Kaoru Maeda 前田 薫
@mad_p
novさん: 疑問: RFC7800ではHolder-of-Key=Presenter=OAuth Clientではないのか #idcon
2016-11-01 19:59:08
Kaoru Maeda 前田 薫
@mad_p
novさん: FAL要件としては署名するか暗号化するか、bearerかholder-of-keyかの組合せでLv1～4が規定されている #idcon
2016-11-01 20:00:39
Kaoru Maeda 前田 薫
@mad_p
novさん: 4つのFederationモデル: Central Authority, Manual Registration, Dynamic Registration, Proxied Federation #idcon
2016-11-01 20:02:12
Kaoru Maeda 前田 薫
@mad_p
novさん: Dynamicについても、trust framework providerによる証明を持っている人だけがdynamic registrationできるモデルも、いきなり登録できるものもある #idcon
2016-11-01 20:02:54
Kaoru Maeda 前田 薫
@mad_p
novさん: Proxied: IdPによるSubscriberのProfiling可能性に対応することができる #idcon
2016-11-01 20:03:29
Kaoru Maeda 前田 薫
@mad_p
novさん: Assertionのカテゴリ。Possessionカテゴリ、Protectionカテゴリ。Possession: h-of-k、bearer; Protection: signed/encrypted/audience restricted/PPID #idcon
2016-11-01 20:04:45
Kaoru Maeda 前田 薫
@mad_p
novさん: Securityの章で、攻撃手法とそれに対する防御策をまとめている(non-normative) #idcon
2016-11-01 20:05:29
Kaoru Maeda 前田 薫
@mad_p
natさん: protection categoryって軸が複数のものが混ざってる。分けさせたほうがいいかも。セキュリティー軸とプライバシー軸が混ざっている #idcon
2016-11-01 20:06:28
Kaoru Maeda 前田 薫
@mad_p
小川さん: セキュリティーのところでnon-normativeになっている理由は? novさん: 理由は書いてない。-2では必須だった natさん: ISO29115でもこうなっていた。リスクに応じてやれということ。単なるチェックリスト化したくないという意図のようだ #idcon
2016-11-01 20:08:03
Kaoru Maeda 前田 薫
@mad_p
samiさん: プロセスについて。登場するロールは2つ。申請者とCSP。登録申請から始まる。CSPは身分証の提示を求める → 検証 → 申請者を登録してcredentialを発行 #idcon
2016-11-01 20:13:30
Kaoru Maeda 前田 薫
@mad_p
samiさん: 以降CSPはcredentialを受けると、登録されたsubscriberとして認証できるようになる #idcon
2016-11-01 20:13:59
Kaoru Maeda 前田 薫
@mad_p
samiさん: 6つのポイント: 実在確認、収集する属性情報、身分証の種類、身分証の検証、アカウント情報の検証、連絡先 #idcon
2016-11-01 20:14:42
Kaoru Maeda 前田 薫
@mad_p
samiさん: 収集する属性情報: Lv2: 一意に識別するために必要な最低限の情報のみに限定。KBVを追加で使ってもよい(knowledge base verification=something you know)、Lv3: 生体情報が必須 #idcon
2016-11-01 20:17:10