Open gioele-antoci opened 1 month ago
RPs should be effectively guided towards implementing a nonce/PKCE flow while associating the authentication exchange with that specific device, for example, by using HttpOnly cookies.
Yeah, that makes sense. A couple of questions:
a) Can we do this as part of the #599 ? @aaronpk WDYT? b) As @bvandersloot-mozilla suggested, is there anything that the browser can do to help? Would some opt-in validation help? E.g. maybe the browser could understand @aaronpk profile and throw errors when certain parameters aren't used?
Instead of returning the token from /assertion, should user agents invoke an RP's callback defined in the configuration file? This approach would alleviate some of the implementation complexity for FedCM RPs and IDPs.
I'd be happy to explore options where the browser can help make the system more secure. I'd still want to do that within the boundaries of what would show up in #599.
TL;DR: Should the FedCM specifications and/or documentation more emphatically warn against device exfiltration attacks?
Context:
/assertion
endpoint returns a token to the front-end channel. The RP's front end is expected to submit the token to the RP's back end to ultimately open a session on the RP.RPs should be effectively guided towards implementing a nonce/PKCE flow while associating the authentication exchange with that specific device, for example, by using
HttpOnly
cookies.Alternative Proposal: Instead of returning the token from
/assertion
, should user agents invoke an RP's callback defined in the configuration file? This approach would alleviate some of the implementation complexity for FedCM RPs and IDPs.Related to: https://github.com/w3c-fedid/FedCM/issues/536 and https://github.com/w3c-fedid/FedCM/issues/599