Yeah, that's what is implied. At least given the way that https://tools.ietf.org/html/draft-ietf-tokbind-https provides to signal to the client to reveal the Referred Token Binding.
I've heard that there's some potential for the Fetch spec to provide some APIs or controls around Token Binding, which might facilitate other ways of getting the Referred Token Binding into a request. But I don't know the details or likelihood or timeline. And whatever form that takes may or may not facilitate other options for 'front-channel' requests to the authorization endpoint. On Wed, May 23, 2018 at 10:27 AM, Daniel Fett <daniel.f...@sec.uni- stuttgart.de> wrote: > > Just to clarify: This implies that there must be an HTTP(S) request from > the browser to the protected resource which then gets redirected to the > authorization endpoint. Is that correct? > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
