I had a comment/question related to the below comment on issue 687 but not really related to the issue itself. So figured the list would be the best forum.<br><br>Regarding the potential use of an ID Token as an assertion in the <span style class="">OAuth</span> <span style class="">JWT</span> Assertion Profile - aren't the requirements around the "<span style class="">aud</span>" claim also potentially a problem? <br>

<br>Connect says the <span style class="">aud</span> of an ID Token "MUST be the <span style class="">OAuth</span> 2.0 client_id of the Client." While the <span style class="">OAuth</span> <span style class="">JWT</span> Assertion Profile is a little more flexible but basically says the <span style class="">aud</span> must identify the AS or its controlling entity. Doesn't this imply that an ID Token could only really be used to get an access token within the scope of the client to whom it was sent in the first place? Which doesn't seem very useful. Or is it?<br>

<br> <br><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 13, 2012 at 5:23 PM, Michael Jones <span dir="ltr"><<a href="mailto:issues-reply@bitbucket.org" target="_blank">issues-reply@<span style class="">bitbucket</span>.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">--- you can reply above this line ---<br>
<br>
Issue 687: Messages - Add 'prn' claim to id_token to support JWT Assertion<br>
<a href="https://bitbucket.org/openid/connect/issue/687/messages-add-prn-claim-to-id_token-to" target="_blank">https://bitbucket.org/openid/connect/issue/687/messages-add-prn-claim-to-id_token-to</a><br>
<br>
</div>Michael Jones:<br>
<br>
<br>
<b>I agree that it would be a shame, architecturally, if we can't use an ID Token as a assertion in a way that complies with the OAuth JWT Assertion Profile. </b> I believe we need to address this.<br>
<br>
There are few ways to do this, as I see it:<br>
<br>
1.  Add "prn" to the ID Token.  Upside:  Simple.  Downsides:  Wastes space through duplication of data; potential interop problem where not everyone duplicates or uses the information in the same way.<br>
<br>
2.  Replace "user_id" with "prn" in the ID Token.  Downside:  Less mnemonic than user_id.  Upside:  simple.<br>
<br>
3.  Modify the OAuth JWT Assertion Profile to allow the subject to be identified by a claim other than "prn" - possibly explicitly calling out "user_id".  Upside:  would work.  Downside:  Codifies inconsistency.<br>


<br>
4.  Replace both "user_id" and "prn" with a different claim in both specs.  Candidates include "id" and "sub".<br>
<br>
Let's make this a topic for Monday's call.<br>
<div class=""><div class="h5"><br>
<br>
--<br>
<br>
This is an issue notification from <a href="http://bitbucket.org" target="_blank">bitbucket.org</a>. You are receiving<br>
this either because you are the owner of the issue, or you are<br>
following the issue.<br>
</div></div></blockquote></div><br></div>