<div dir="ltr">Yes, and that was one of the reason why I think azp MUST be a client_id is too restrictive. <div style>In my original text, it was "an identifier" which the application should define. </div><div style>
It could be a public key of the client, or JWT that has the original claims, just like in ActAs. </div><div style>In HoK context, it could be anything that binds the token to the key. </div><div style><br></div><div style>
Nat</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/3/29 John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">OnBehalfOf is a RST element not a RSTR element. <div><br></div><div>Normally the id_token contains claims about the sub who in our case is the user.</div><div><br></div><div>When a id_token is requested from the token endpoint and no azp is inserted it is the same as a WS security token being requested with OnBehalfOf the subject in that there are only claims about sub.</div>
<div><br></div><div>If azp is included in the response because the audience is different from the requester then it is more like ActAs where the token is a composite of claims about the subject and the requester.</div><div>
<br></div><div>The difference is that in WS the resulting token has claims about the requester and one of those claims is ActAs containing claims about the original subject.</div><div><br></div><div>The azp claim is a claim about the requester, and that the token endpoint has authenticated that requester.</div>
<div><br></div><div>In the WS case the end consuming service is not validating the identity of the presenter that was done by the STS.</div><div><br></div><div>Now that might be an argument for the 'azp' information to be a set of claims so that proof of possession can be part of that delegation.</div>
<div><br></div><div>So a token with 'azp' indicates that it was requested by a client and that the AS is delegating it the ability to ActAs the subject in some way. </div><div><br></div><div>It may be useful to the recipient of the token to be able to tell what client is presenting the token. </div>
<div><br></div><div>One concern is that we don't want client A requesting a token for user Bob with a aud of B and then using that token at B in the front channel and pretending to be Bob rather than A acting on behalf of BoB, they are different things. So there is an important security reason to mark tokens with who requested them if the requester and aud are different. A token with 'azp' MUST not be taken in the front channel.</div>
<div><br></div><div>You made me think WS-* again curse you!</div><div><br></div><div><br></div><div><div><div><div class="h5"><div>On 2013-03-28, at 9:46 PM, Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>> wrote:</div>
<br></div></div><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple" style="font-family:Helvetica;font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div><div class="h5"><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I think we may be largely agreeing in substance but use different words to express the same thing.<u></u><u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">In my mind, if the client gives its bearer token to another legitimate piece of code to perform an action for it, then it is logically part of the implementation of the client. The presenter logically remains the client to whom the token was issued. It’s as if no sharing occurred.<u></u><u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">However, when the client explicitly gives a token with azp in it to a different authorized client, which is performing actions for itself and not directly as part of the client to whom the token was issued, that’s a different case. In that case, I can see why “azp” is wanted to identify the second client as an authorized party, since it is acting on its own behalf, and not on behalf of the original client. (Yes, I understand their actions may be aligned in purpose and coordinated, but that doesn’t make them the same OAuth client.)<u></u><u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Also, I’m pretty sure that we can agree that if the token is leaked by either party to an unauthorized party, that it’s always a security bug, and not a legitimate use of the token.<u></u><u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> -- Mike<u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><b><span style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"><span> </span>Nat Sakimura [mailto:<a href="mailto:sakimura@" target="_blank">sakimura@</a><a href="http://gmail.com" target="_blank">gmail.com</a>]<span> </span><br>
<b>Sent:</b><span> </span>Thursday, March 28, 2013 5:29 PM<br><b>To:</b><span> </span>Mike Jones<br><b>Cc:</b><span> </span>Tim Bray; openid-specs-ab<br><b>Subject:</b><span> </span>Re: [Openid-specs-ab] OpenID Connect and Identity Delegation<u></u><u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><u></u> <u></u></div><p class="MsoNormal" style="margin:0in 0in 12pt;font-size:12pt;font-family:'Times New Roman',serif">
Inline: <u></u><u></u></p><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">2013/3/29 Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" style="color:purple;text-decoration:underline" target="_blank">Michael.Jones@microsoft.com</a>><u></u><u></u></div>
<div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">“azp” isn’t an OAuth construct – it’s an OpenID Connect construct that we’ve defined (although apparently not precisely enough that we have broad agreement on what it means and how it’s used). I think the outcome of this thread should be to clarify the definition so others will understand better what was intended and what wasn’t.</span><u></u><u></u></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">My logic is that if it was legitimate to just hand off the token from one client to another without any indication that it’s OK to do so, we wouldn’t need “azp” at all; we’d just give the token to the other presenter and it would happily use it. </span><u></u><u></u></div>
</div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><u></u> <u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
That actually is the notion of bearer as generally (i.e., not only in OAuth world) understood. Also, the OAuth specs does not preclude it. <u></u><u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
<u></u><u></u></div></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in"><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">“azp” is there as a declaration that, in this particular case, the handoff was authorized, and that that the party identified in the “azp” claim is a legitimate presenter, even though it was not the requester of the token. Hence, without “azp”, the token is scoped to the requesting client as the sole authorized presenter.</span><u></u><u></u></div>
</blockquote><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><u></u> <u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
To me, azp is the explicit restriction on who can use the token. <u></u><u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">Bearer has no restriction like that. Or, if it does, it should change its name as well as add text about it in the spec. <u></u><u></u></div>
</div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"> <u></u><u></u></div></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">In summary, if handoff to arbitrary parties was OK, we wouldn’t need “azp” in the first place.</span><u></u><u></u></div></blockquote><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
<u></u> <u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">As long as the spec text does not preclude it, it is ok, and it seems it is ok from the current text and the naming of it. The security model of the bearer is contingent on how securely you can hold onto the token. In the real world, it is equivalent to how securely you can hold onto your cash, which is a prime example of a bearer instrument. It is also perfectly fine for you to give the cash to your wife to dispense. This does not happen in the case of a credit card, which is not a bearer instrument but a registered instrument with card holder name as "azp". <u></u><u></u></div>
</div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><u></u> <u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
Nat<u></u><u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"> <u></u><u></u></div></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> -- Mike</span><u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><b><span style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"><span> </span>Nat Sakimura [mailto:<a href="mailto:sakimura@gmail.com" style="color:purple;text-decoration:underline" target="_blank">sakimura@gmail.com</a>]<span> </span><br>
<b>Sent:</b><span> </span>Thursday, March 28, 2013 5:06 PM</span><u></u><u></u></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><br><b>To:</b><span> </span>Mike Jones<br>
<b>Cc:</b><span> </span>Tim Bray; openid-specs-ab<br><b>Subject:</b><span> </span>Re: [Openid-specs-ab] OpenID Connect and Identity Delegation<u></u><u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">Could you point me to the text in OAuth spec describing it? <u></u><u></u></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
<u></u><u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">Also, there are legitimate cases where changing hands happens, which is not leaking. <u></u><u></u></div>
</div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">As long as the original party that has gotten the bearer token is consciously handing it to another client, it should be fine. e.g., sometimes connected client handing it to the server component that has a different client_id. <u></u><u></u></div>
</div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"> <u></u><u></u></div></div><div><p class="MsoNormal" style="margin:0in 0in 12pt;font-size:12pt;font-family:'Times New Roman',serif">
Nat<u></u><u></u></p><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">2013/3/29 Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" style="color:purple;text-decoration:underline" target="_blank">Michael.Jones@microsoft.com</a>><u></u><u></u></div>
<div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Changing hands doesn’t mean that it’s authorized. It just means that the token has been leaked to an unauthorized party.</span><u></u><u></u></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> -- Mike</span><u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><b><span style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"><span> </span>Nat Sakimura [mailto:<a href="mailto:sakimura@gmail.com" style="color:purple;text-decoration:underline" target="_blank">sakimura@gmail.com</a>]<span> </span><br>
<b>Sent:</b><span> </span>Thursday, March 28, 2013 4:51 PM<br><b>To:</b><span> </span>Mike Jones<br><b>Cc:</b><span> </span>Tim Bray; openid-specs-ab</span><u></u><u></u></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
<br><b>Subject:</b><span> </span>Re: [Openid-specs-ab] OpenID Connect and Identity Delegation<u></u><u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"> <u></u><u></u></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">Which is not the case that it may sometime change the hand. The name bearer suggests otherwise as well. Bearer is whoever has it. <u></u><u></u></div>
<div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"> <u></u><u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
>From Oxford Dictionary: <u></u><u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"> <u></u><u></u></div></div><blockquote style="margin:5pt 0in 5pt 30pt">
<div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><b><span style="color:rgb(51,51,51);font-size:9pt;font-family:Georgia,serif;padding:0in;border:1pt none windowtext;background-repeat:initial initial">1</span></b><span style="color:rgb(51,51,51);font-size:9pt;font-family:Georgia,serif;padding:0in;border:1pt none windowtext;background-repeat:initial initial">a person or thing that carries or holds something:</span><u></u><u></u></div>
</div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><b><span style="color:rgb(51,51,51);font-size:9pt;font-family:Georgia,serif;padding:0in;border:1pt none windowtext;background-repeat:initial initial">2</span></b><span style="color:rgb(51,51,51);font-size:9pt;font-family:Georgia,serif;background-repeat:initial initial">a person who presents a cheque or other order to pay money:</span><u></u><u></u></div>
</div></blockquote><div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"> <u></u><u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
And here is a description of "bearer bond" from wikipedia: <u></u><u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"> <u></u><u></u></div></div>
</div><blockquote style="margin:5pt 0in 5pt 30pt"><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:10pt;font-family:Arial,sans-serif;background-repeat:initial initial">A <b>bearer bond</b> is a debt security issued by a business entity, such as a corporation, or by a government. It differs from the more common types of investment securities in that it is unregistered – no records are kept of the owner, or the transactions involving ownership. Whoever physically holds the paper on which the bond is issued owns the </span><a href="http://en.wikipedia.org/wiki/Financial_instrument" title="Financial instrument" style="color:purple;text-decoration:underline" target="_blank"><span style="color:rgb(11,0,128);font-size:10pt;text-decoration:none;font-family:Arial,sans-serif;background-repeat:initial initial">instrument</span></a><span style="font-size:10pt;font-family:Arial,sans-serif;background-repeat:initial initial">. This is useful for </span><a href="http://en.wikipedia.org/wiki/Investor" title="Investor" style="color:purple;text-decoration:underline" target="_blank"><span style="color:rgb(11,0,128);font-size:10pt;text-decoration:none;font-family:Arial,sans-serif;background-repeat:initial initial">investors</span></a><span style="font-size:10pt;font-family:Arial,sans-serif;background-repeat:initial initial"> who wish to retain anonymity. Recovery of the value of a bearer bond in the event of its loss, theft, or destruction is usually impossible. </span><u></u><u></u></div>
</blockquote><div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"> <u></u><u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
At the same time, bearer is more privacy preserving in some sense. In a "registered token", i.e., token with the "azp", it is impossible to hide who is presenting it. <u></u><u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
<u></u><u></u></div></div><div><p class="MsoNormal" style="margin:0in 0in 12pt;font-size:12pt;font-family:'Times New Roman',serif">Nat<u></u><u></u></p><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
<u></u><u></u></div></div></div></div></div></div></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">--<span> </span><br>Nat Sakimura (=nat)<u></u><u></u></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" style="color:purple;text-decoration:underline" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en<u></u><u></u></div></div></div></div></blockquote></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><br><br clear="all"><u></u><u></u></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
<u></u> <u></u></div></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">--<span> </span><br>Nat Sakimura (=nat)<u></u><u></u></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" style="color:purple;text-decoration:underline" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en<u></u><u></u></div></div></div></div></div><div class="im">
_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></div>
</div></blockquote></div><br></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en</div>
</div>