<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<blockquote type="cite">Somewhat tangentally though is that JWT only
allows for a single audience to be identified in the token.</blockquote>
<br>
On reading Brian's note I reread the 'aud' section in the JWT spec.
It is a single 'aud' claim but and I don't see it as being limited
to a single principal. It says the principal processing the token
must be identified in the claim and that the interpretation is
application specific, but I don't see a limit of one. It does add a
lot of flexibility to specify more than one -- which could be good
or bad -- and we do so in our implementation. We commonly generate
JWTs that have an RS and the AS identified in the audience. If it
could also help in the OIDC cases, I think that could be an option.
Or did I miss something in the JWT spec?<br>
<br>
--Dale<br>
<br>
<br>
<div class="moz-cite-prefix">On 12/14/2012 03:11 PM, Brian Campbell
wrote:<br>
</div>
<blockquote
cite="mid:CA+k3eCTt_KUMUKtNry3gOTXfZXu5Ppy7EVk905TZTW3RRVPsQw@mail.gmail.com"
type="cite">That's one way to go.<br>
<br>
The assertion drafts are mostly about using the assertion to cross
organizational boundaries (though I guess not necessarily). Some
trusted party issues an assertion and says who it's for. The
consumer of the assertion makes sure it was intended for them.
This seems is a special case of that where the issuer is also one
of the indented audiences. The SAML draft would allow this
situation by allowing for more than one acceptable audience to be
included in the token (but you can't do that in JWT). And I'm not
aware of anyone actually doing that kind of thing in practice with
SAML now. I'm not sure it's the right way to approach it for that
matter.<br>
<br>
Alternatively the AS could have some special condition on audience
validation for tokens that it issued itself. That's a pattern I've
heard suggested several times before for various things but,
though I can't say exactly why, I've never been real fond of it. <br>
<br>
I'm not sure exactly what should be done with the case you
describe.<br>
<br>
Somewhat tangentally though is that JWT only allows for a single
audience to be identified in the token. I've been wondering to
myself for some time now if that's too restrictive. Being able to
indicated more than one intended audience in a token seems like it
would add a lot of flexibility to a number of these various token
exchange type scenarios. But then again SAML has that and I don't
know how much it gets utilized. So maybe it would just be adding
unneeded complexity.<br>
<br>
I'm going to stop rambling now...<br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Dec 14, 2012 at 3:40 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>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?<span class="HOEnZb"><font
color="#888888"><br>
<br>
-- Justin</font></span>
<div>
<div class="h5"><br>
<br>
On 12/14/2012 04:51 PM, Brian Campbell wrote:<br>
</div>
</div>
</div>
<div>
<div class="h5">
<blockquote type="cite"> 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><br>
<br>
On 12/14/2012 04:04 PM, Brian Campbell
wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div> 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>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
</body>
</html>