<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
tt
{mso-style-priority:99;
font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";
color:black;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks. This is an actual JWT technical issue being considered at present, so your implementation/usage experience would be highly pertinent at this juncture.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> -- Mike<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"> Dale Olds [mailto:olds@rbcon.com]
<b>On Behalf Of </b>Dale Olds<br>
<b>Sent:</b> Tuesday, December 18, 2012 3:18 PM<br>
<b>To:</b> Mike Jones<br>
<b>Cc:</b> Brian Campbell; <openid-specs-ab@lists.openid.net><br>
<b>Subject:</b> Re: [Openid-specs-ab] [openid/connect] Messages - Add 'prn' claim to id_token to support JWT Assertion (issue #687)<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Thanks, Mike. I hadn't seen that. I am on the OAuth2 list but rarely feel the need to say anything. I'll float my opinion there.
<br>
<br>
My intent here was not to argue a JWT issue (i didn't think it was an issue) but to suggest possible ways to help in resolving oidc use cases.
<br>
<br>
--Dale<o:p></o:p></p>
<div>
<p class="MsoNormal">On 12/18/2012 03:00 PM, Mike Jones wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Dale, there’s a thread about adding the “aud”:[list] syntax to JWT on the OAuth list (where JWT is actually being defined) right now. See
<a href="http://www.ietf.org/mail-archive/web/oauth/current/msg10285.html">http://www.ietf.org/mail-archive/web/oauth/current/msg10285.html</a>. I’d suggest joining the list at
<a href="https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a> and sending a note supporting this addition. I’d be sure to point out that you’re already using it in practice.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">That would help move the discussion along on that topic.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> Thanks,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> -- Mike</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">
<a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a> [<a href="mailto:openid-specs-ab-bounces@lists.openid.net">mailto:openid-specs-ab-bounces@lists.openid.net</a>]
<b>On Behalf Of </b>Dale Olds<br>
<b>Sent:</b> Tuesday, December 18, 2012 2:38 PM<br>
<b>To:</b> Brian Campbell<br>
<b>Cc:</b> <a href="mailto:openid-specs-ab@lists.openid.net"><openid-specs-ab@lists.openid.net></a><br>
<b>Subject:</b> Re: [Openid-specs-ab] [openid/connect] Messages - Add 'prn' claim to id_token to support JWT Assertion (issue #687)</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Hey Brian, <br>
<br>
To your question: yes, regular access tokens. We follow a convention of RS.CoarsePermission in defining scopes. So if a user delegated to a client authorization to read their openid info, modify their resources on the cloud controller, and read users and groups
on their behalf -- we *could* combine that in single token (not that that's a good idea). The oauth2 scope would look like "openid cloud_controller.write scim.read". The JWT access token would contain "aud":["openid","cloud_controller","scim"]. Such a token
could be presented to the oidc /userinfo endpoint, the scim /Users and /Groups endpoints, and the cloud_controller endpoints. Each endpoint validates the token and verifies that it is in the intended audience list. This approach had been quite useful and flexible.
The downside is that we are not completely insulating the RSs from each other. In our case we never actually combine user account management with cloud controller access and since the services are all in the same management domain and we felt potential abuse
was low when sharing access to the openid /userinfo. <br>
<br>
IIRC we made some of our implementation choices due to a comment from Mike Jones that (from memory) went something like this: while 'aud' or other JWT claims are each single claims the J stands for JSON, so an array is a fine value. Made sense to me. Therefore
our tokens look like your last example of "aud":["Dale","Brian"].<br>
<br>
--Dale<o:p></o:p></p>
<div>
<p class="MsoNormal">On 12/17/2012 07:52 AM, Brian Campbell wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-bottom:12.0pt">You're right Dale, there's nothing that says it can only be a single principal. But aud's current definition as a single StringOrURI value does mean that identifying more than one principal would have to be
done by somehow encoding that fact into a single value. Maybe a value that represents a group or some delimiter or something. But interpretations of that that kind of thing seem likely to be very application specific. And some specs might have restrictions/requirements
that make that kind of thing difficult too - like Connect specifies that the aud of the ID Token be the client id of the client/RP.
<br>
<br>
You say you commonly generate JWTs that have an RS and the AS identified in the audience. I assume those are regular access tokens? What does that look like?
<br>
<br>
Trying to explain what I'm thinking a bit more, by way of example, if we wanted to produce a JWT that indicated either you or I as an intended audience, we'd have to do something like "aud":"DaleOrBrian" or "aud":"some-group-identifier" where some-group-identifier
indicates a group that we both understand and consider ourselves part of. <br>
<br>
I'm wondered if this kind of thing is common enough that the JWT should try and help accommodate it by allowing for multiple values to be present in the aud claim as an array and stating that the consumer of the JWT must identify itself with one of those values.
So a token sent to either you our I might have an audience claim that looks like, "aud":["Dale", "Brian"].<br>
<br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> <o:p></o:p></p>
<div>
<p class="MsoNormal">On Sat, Dec 15, 2012 at 1:53 PM, Dale Olds <<a href="mailto:olds@vmware.com" target="_blank">olds@vmware.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">Somewhat tangentally though is that JWT only allows for a single audience to be identified in the token.<o:p></o:p></p>
</blockquote>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal">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?<span style="color:#888888"><br>
<br>
--Dale</span> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal">On 12/14/2012 03:11 PM, Brian Campbell wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">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...<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> <o:p></o:p></p>
<div>
<p class="MsoNormal">On Fri, Dec 14, 2012 at 3:40 PM, Justin Richer <<a href="mailto:jricher@mitre.org" target="_blank">jricher@mitre.org</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">You are correct. I hadn't caught that, but it does state in JWT Assertions:<o:p></o:p></p>
<p class="MsoNormal">The JWT MUST contain an <tt><span style="font-size:10.0pt">aud</span></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><span style="font-size:10.0pt">aud</span></tt> element. The authorization server MUST verify that it is an intended audience for the JWT.
<o:p></o:p></p>
<p class="MsoNormal"><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 style="color:#888888"><br>
<br>
-- Justin</span> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
<br>
On 12/14/2012 04:51 PM, Brian Campbell wrote:<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-bottom:12.0pt">I believe the current wording of the specs would prohibit that.
<br>
<br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> <o:p></o:p></p>
<div>
<p class="MsoNormal">On Fri, Dec 14, 2012 at 2:10 PM, Justin Richer <<a href="mailto:jricher@mitre.org" target="_blank">jricher@mitre.org</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">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 <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
<br>
On 12/14/2012 04:04 PM, Brian Campbell wrote:<o:p></o:p></p>
</div>
</div>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">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 OAuth JWT Assertion Profile - aren't the requirements around the "aud" claim also potentially a problem?
<br>
<br>
Connect says the aud of an ID Token "MUST be the OAuth 2.0 client_id of the Client." While the OAuth JWT Assertion Profile is a little more flexible but basically says the aud 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>
<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> <o:p></o:p></p>
<div>
<p class="MsoNormal">On Thu, Dec 13, 2012 at 5:23 PM, Michael Jones <<a href="mailto:issues-reply@bitbucket.org" target="_blank">issues-reply@bitbucket.org</a>> wrote:<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">--- 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><o:p></o:p></p>
</div>
<p class="MsoNormal">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.<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><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.<o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
</div>
</div>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Openid-specs-ab mailing list<o:p></o:p></pre>
<pre><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><o:p></o:p></pre>
<pre><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</blockquote>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Openid-specs-ab mailing list<o:p></o:p></pre>
<pre><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><o:p></o:p></pre>
<pre><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<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><o:p></o:p></p>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</blockquote>
<p class="MsoNormal"> <o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>