I believe the current wording of the specs would prohibit that. <br><br><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Dec 14, 2012 at 2:10 PM, Justin Richer <span dir="ltr"><<a href="mailto:jricher@mitre.org" target="_blank">jricher@mitre.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>My original idea is for the Client to
      use the JWT Assertion flow with a current id_token to refresh it
      and get a new id_token. This goes back to the session management
      proposal linked to within the issue. In this case, the audience
      for the token really *is* the client, and an AS will need to look
      for that.<br>
      <br>
       -- Justin<div><div class="h5"><br>
      <br>
      On 12/14/2012 04:04 PM, Brian Campbell wrote:<br>
    </div></div></div>
    <blockquote type="cite"><div><div class="h5">
      
      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>OAuth</span> <span>JWT</span>
      Assertion Profile - aren't the requirements around the "<span>aud</span>" claim also potentially a problem?
      <br>
      <br>
      Connect says the <span>aud</span> of an ID
      Token "MUST be the <span>OAuth</span> 2.0
      client_id of the Client." While the <span>OAuth</span>
      <span>JWT</span> Assertion Profile is a little
      more flexible but basically says the <span>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>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>--- 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>
              <div><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>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><pre>_______________________________________________
Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
    </blockquote>
    <br>
  </div>

</blockquote></div><br></div>