<div dir="auto">I talked to Nat about this a bit today.  <div dir="auto"><br></div><div dir="auto">The thing he is concerned about is mostly around the self issued IDP that doesn't have a token endpoint(atleast not easaly).  </div><div dir="auto"><br></div><div dir="auto">The main use case for that is the id_token response type where claims are retuned in the id_token.  </div><div dir="auto"><br></div><div dir="auto">Because it is fragment encoded some people call that implicit.   That is not what we are trying to stop.   </div><div dir="auto"><br></div><div dir="auto">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.  </div><div dir="auto"><br></div><div dir="auto">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.  </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">This is a touch hypothetical from the basic OAuth perspective, so I don't know how deep we want to go into it.</div><div dir="auto"><br></div><div dir="auto">I think the point is not to accidently prohibit something that could be done in future.  </div><div dir="auto"><br></div><div dir="auto">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.  </div><div dir="auto"><br></div><div dir="auto">John B. </div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 27, 2018, 4:30 PM Torsten Lodderstedt via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Nat, <br>
<br>
I understand you are saying your draft could provide clients with an application level mechanism to sender constrain access tokens. That’s great! <br>
<br>
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? <br>
<br>
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.<br>
<br>
kind regards,<br>
Torsten.<br>
<br>
> Am 27.11.2018 um 16:57 schrieb Nat Sakimura <<a href="mailto:sakimura@gmail.com" target="_blank" rel="noreferrer">sakimura@gmail.com</a>>:<br>
> <br>
> I am not talking about SPA. <br>
> The client is a regular confidential client that is running on a server. <br>
> <br>
> Best, <br>
> <br>
> Nat Sakimura<br>
> <br>
> <br>
> 2018年11月27日(火) 16:55 Jim Manico <<a href="mailto:jim@manicode.com" target="_blank" rel="noreferrer">jim@manicode.com</a>>:<br>
> Nat,<br>
> <br>
> How is proof of possession established in a modern web browser in the implicit flow?<br>
> <br>
> My understanding is that token binding was removed from Chrome recently effectively killing browser-based PoP tokens.<br>
> <br>
> <a href="https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/" rel="noreferrer noreferrer" target="_blank">https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/</a><br>
> <br>
> Am I missing something?<br>
> <br>
> Aloha, Jim<br>
> <br>
> <br>
> <br>
> On 11/27/18 9:00 PM, Nat Sakimura wrote:<br>
>> I am actually -1. <br>
>> <br>
>> +1 for public client and the tokens that are not sender/key constrained. <br>
>> <br>
>> Just not being used right now does not mean that it is not useful.. In fact, I see it coming. <br>
>> Implicit (well, Hybrid “token id_token” really) is very useful in certain cases. <br>
>> Specifically, when the client is confidential (based on public key pair), and uses sender constrained (key-constrained) token such as the one explained in <a href="https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5" rel="noreferrer noreferrer" target="_blank">https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5</a>, it is very useful. <br>
>> (Key-constrained token is the remaining portion of this draft that did not get incorporated in the MTLS draft. )<br>
>> In fact it is the only viable method for Self-Issued OpenID Provider. <br>
>> <br>
>> 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, ... “<br>
>> <br>
>> Best, <br>
>> <br>
>> Nat Sakimura<br>
>> <br>
>> <br>
>> 2018年11月27日(火) 16:01 Vladimir Dzhuvinov <<a href="mailto:vladimir@connect2id.com" target="_blank" rel="noreferrer">vladimir@connect2id.com</a>>:<br>
>> +1 to recommend the deprecation of implicit.<br>
>> <br>
>> I don't see a compelling reason to keep implicit when there is an<br>
>> established alternative that is more secure.<br>
>> <br>
>> Our duty as WG is to give developers the best and most sensible practice.<br>
>> <br>
>> CORS adoption is currently at 94% according to<br>
>> <a href="https://caniuse.com/#feat=cors" rel="noreferrer noreferrer" target="_blank">https://caniuse.com/#feat=cors</a><br>
>> <br>
>> Vladimir<br>
>> <br>
>> <br>
>> _______________________________________________<br>
>> OAuth mailing list<br>
>> <a href="mailto:OAuth@ietf.org" target="_blank" rel="noreferrer">OAuth@ietf.org</a><br>
>> <a href="https://www.ietf.org/mailman/listinfo/oauth" rel="noreferrer noreferrer" target="_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br>
>> -- <br>
>> Nat Sakimura (=nat)<br>
>> Chairman, OpenID Foundation<br>
>> <a href="http://nat." rel="noreferrer noreferrer" target="_blank">http://nat.</a>.<a href="http://sakimura.org/" rel="noreferrer noreferrer" target="_blank">sakimura.org/</a><br>
>> @_nat_en<br>
>> <br>
>> <br>
>> _______________________________________________<br>
>> OAuth mailing list<br>
>> <br>
>> <a href="mailto:OAuth@ietf.org" target="_blank" rel="noreferrer">OAuth@ietf.org</a><br>
>> <a href="https://www.ietf.org/mailman/listinfo/oauth" rel="noreferrer noreferrer" target="_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br>
> -- <br>
> Jim Manico<br>
> Manicode Security<br>
> <br>
> <a href="https://www.manicode.com" rel="noreferrer noreferrer" target="_blank">https://www.manicode.com</a><br>
> -- <br>
> Nat Sakimura (=nat)<br>
> Chairman, OpenID Foundation<br>
> <a href="http://nat.sakimura.org/" rel="noreferrer noreferrer" target="_blank">http://nat.sakimura.org/</a><br>
> @_nat_en<br>
> _______________________________________________<br>
> OAuth mailing list<br>
> <a href="mailto:OAuth@ietf.org" target="_blank" rel="noreferrer">OAuth@ietf.org</a><br>
> <a href="https://www.ietf.org/mailman/listinfo/oauth" rel="noreferrer noreferrer" target="_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br>
<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank" rel="noreferrer">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>