I am not talking about SPA. The client is a regular confidential client that is running on a server.
Best, Nat Sakimura 2018年11月27日(火) 16:55 Jim Manico <j...@manicode.com>: > Nat, > > How is proof of possession established in a modern web browser in the > implicit flow? > > My understanding is that token binding was removed from Chrome recently > effectively killing browser-based PoP tokens. > > https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/ > > Am I missing something? > > Aloha, Jim > > > On 11/27/18 9:00 PM, Nat Sakimura wrote: > > I am actually -1. > > +1 for public client and the tokens that are not sender/key constrained. > > Just not being used right now does not mean that it is not useful.. In > fact, I see it coming. > > Implicit (well, Hybrid “token id_token” really) is very useful in certain > cases. > Specifically, when the client is confidential (based on public key pair), > and uses sender constrained (key-constrained) token such as the one > explained in > https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it is > very useful. > (Key-constrained token is the remaining portion of this draft that did not > get incorporated in the MTLS draft. ) > In fact it is the only viable method for Self-Issued OpenID Provider. > > So, the text is generally good but it needs to be constrained like “Unless > the client is confidential and the access token issued is key constrained, > ... “ > > Best, > > Nat Sakimura > > > 2018年11月27日(火) 16:01 Vladimir Dzhuvinov <vladi...@connect2id.com>: > >> +1 to recommend the deprecation of implicit. >> >> I don't see a compelling reason to keep implicit when there is an >> established alternative that is more secure. >> >> Our duty as WG is to give developers the best and most sensible practice.. >> >> CORS adoption is currently at 94% according to >> https://caniuse.com/#feat=cors >> >> Vladimir >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > -- > Jim Manico > Manicode Securityhttps://www.manicode.com > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
