Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security Topics -- Recommend authorization code instead of implicit

[John Bradley <[e-mail]>]

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 <[e-mail]>:
>>
>> 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 <[e-mail] 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 <[e-mail]>:
>>>
>>> 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 <[e-mail]>:
>>> 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 <[e-mail]>:
>>>> +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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> -- 
>>>> Nat Sakimura (=nat)
>>>> Chairman, OpenID Foundation
>>>> http://nat..sakimura.org/
>>>> @_nat_en
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>>
>>>> [e-mail]
>>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> Openid-specs-ab mailing list
>> [e-mail]
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab