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 list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
