Hi John, as you said, self issued IDPs (https://openid.net/specs/openid-connect-core-1_0.html#SelfIssued) are supposed to provide the response type „id_token“ only. I don’t think the proposal being discussed here is related to this OIDC mode.
best regards, Torsten. > Am 27.11.2018 um 20:54 schrieb John Bradley <ve7...@ve7jtb.com>: > > I talked to Nat about this a bit today. > > The thing he is concerned about is mostly around the self issued IDP that > doesn't have a token endpoint(atleast not easaly). > > The main use case for that is the id_token response type where claims are > retuned in the id_token. > > Because it is fragment encoded some people call that implicit. That is not > what we are trying to stop. > > In some cases in that flow there may be distributed claims returned with > access Token inside the id_token. I think most people would agree that > those should be pop or sender constrained tokens. > > In the case of self issued the RP would be a server and could do sender > constrained via some mechinisim that is yet to be defined. > > So if someone wanted to return a access token in a id_token to do distributed > claims I don't think we have a problem with that as long as the token is > protected by being sender constrained in some reasonable way. > > This is a touch hypothetical from the basic OAuth perspective, so I don't > know how deep we want to go into it. > > I think the point is not to accidently prohibit something that could be done > in future. > > I also think we should not conflate confidential clients that can > authenticate to the token endpoint with sender constrained/PoP clients that > can deal with bound tokens. Yes both have keys but it is better to describe > them separately. > > John B. > > On Tue, Nov 27, 2018, 4:30 PM Torsten Lodderstedt via Openid-specs-ab > <openid-specs...@lists.openid.net wrote: > Hi Nat, > > I understand you are saying your draft could provide clients with an > application level mechanism to sender constrain access tokens. That’s great! > > But I don’t see a binding to response type „token id_token“. Why do you want > to expose the tokens via the URL to attackers? > > You could easily use your mechanism with code. That would also give you the > chance to really authenticate the confidential client before you issue the > token. > > kind regards, > Torsten. > > > Am 27.11.2018 um 16:57 schrieb Nat Sakimura <sakim...@gmail.com>: > > > > 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 list > >> > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > -- > > Jim Manico > > Manicode Security > > > > https://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 > > _______________________________________________ > Openid-specs-ab mailing list > openid-specs...@lists.openid.net > http://lists.openid.net/mailman/listinfo/openid-specs-ab
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
