[Openid-specs-fastfed] Draft 00 feedback - redirect approach CSRF/XSRF

[Phil Hunt]

Darin,

Thanks for putting pen to the discussion and publishing the proposed draft: 
http://openid.net/specs/fastfed-1_0-00.html <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_specs_fastfed-2D1-5F0-2D00.html&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=R4edHOJ4D3y6Io0IIy7FDhWt7otbYR_u-URtfF102-8&s=jlQ7jhJB9MTS8gtpPAGr3YLwrx0_SX56qezj8FK24dM&e=>

While FastFed is very important to my organization, I have substantial worries about FastFed being a two-edge sword and a thus a potential attack vector.

I like the idea, that requests are authorized and initiated using administrator credentials. But in an every expanding scope of relationships, trust based on administrators can be somewhat weak.

Can you comment about how you propose to secure the spec from CSRF/XSRF attacks in the multi-step, multi-redirect process?  In the case of OAuth this has been the single most difficult thing to lock down causing all sorts of new requirements such as we see in FAPI and iGov.

Why not pursue an approach that is more of an evolution of the OIDC Dynamic Registration & Metadata approach that works in the back-channel?

With regards to the metadata and mapping, I think this is a great start.

All the best,

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com <http://www.independentid.com/>phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fastfed/attachments/20171129/9bb9102c/attachment.html>