I still don’t understand why the use case must be solved using a flow issuing something in the front channel.
I would also like to take a closer look. Can you or Nat provide pointers to existing implementations? > Am 27.11.2018 um 21:36 schrieb John Bradley <ve7...@ve7jtb.com>: > > I understand that, but hat is Nat's concern as I understand it. > > When we say no implicit people, have a problem because implicit is imprecise. > > We are saying no AT returned in the response from the authorization endpoint. > > Nat points out that id_token may contain AT for the self issued client. > > So unless we say that is OK if the AT are sender constrained we wind up > implying that a OpenID profile of OAuth is in violation of the BCP. > > I am just trying to make sure everyone is on the same page with why Nat was > -1. > > It really has nothing to do with the SPA use case. > > John B. > >> On 11/27/2018 5:28 PM, Torsten Lodderstedt wrote: >> 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
