<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">You are correct. I hadn't caught that,
but it does state in JWT Assertions:<br>
<br>
<blockquote>The JWT MUST contain an <tt>aud</tt> (audience) claim
containing a URI reference that identifies the authorization
server, or the service provider principal entity of its
controlling domain, as an intended audience. The token endpoint
URL of the authorization server MAY be used as an acceptable
value for an <tt>aud</tt> element. The authorization server
MUST verify that it is an intended audience for the JWT. <br>
</blockquote>
<br>
Which doesn't leave much wiggle room for the OIDC interpretation.
Between this an 'prn', maybe this is a different kind of assertion
claim, then? An id-token assertion grant type?<br>
<br>
-- Justin<br>
<br>
On 12/14/2012 04:51 PM, Brian Campbell wrote:<br>
</div>
<blockquote
cite="mid:CA+k3eCTqS1A1PLH5TuYqivf9GCX8VwtVGnM2UQJLhxK5kR3K+g@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
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 moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a moz-do-not-send="true" 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>
</blockquote>
<br>
</body>
</html>