Ok, thanks! - Daniel
Am 24.05.18 um 23:57 schrieb Brian Campbell: > 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 > <mailto: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./ -- SEC - Institute of Information Security University of Stuttgart Phone +49 711 685 88468 Universitätsstraße 38 - 70569 Stuttgart - Room 2.434
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
