I opt for (4) - Remove support/description of binding of access tokens issued from the authorization endpoint
I think the potential solution we worked out (slide 6) is to complex and the security implications of the redirect via the resource servers are still unclear. > Am 18.11.2018 um 13:32 schrieb Brian Campbell > <bcampbell=40pingidentity....@dmarc.ietf.org>: > > During the first OAuth session in Bangkok the question "what to do about > token binding & implicit?" was raised. There was some discussion but session > time was limited and we had to move on before any real consensus was reached. > > So I thought I'd bring the question to the WG list to generate some more > discussion on the issue. It's also related, at least in part, to a couple of > the other ongoing threads on the list about browser based apps and security > practices. > > The slides from the session are linked below. Slides 5 & 6 try and explain > the awkwardness of doing Token Binding with implicit. While slide 7 lays out > some (not very good) options for how to proceed. > https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-token-binding-00 > > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
