<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
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<br>
<br>
<div class="moz-cite-prefix">On 12/18/2012 03:00 PM, Mike Jones
wrote:<br>
</div>
<blockquote
cite="mid:4E1F6AAD24975D4BA5B1680429673943669697FA@TK5EX14MBXC283.redmond.corp.microsoft.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<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";}
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-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]-->
<div class="WordSection1">
<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 moz-do-not-send="true"
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 moz-do-not-send="true"
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.<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">That
would help move the discussion along on that topic.<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">
<a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>
[<a class="moz-txt-link-freetext" 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 class="moz-txt-link-rfc2396E" 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)<o:p></o:p></span></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>
<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 moz-do-not-send="true"
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>
<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
moz-do-not-send="true"
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>
<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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
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><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
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.<o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><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 moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><o:p></o:p></pre>
<pre><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><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>
<o:p></o:p></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Openid-specs-ab mailing list<o:p></o:p></pre>
<pre><a moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><o:p></o:p></pre>
<pre><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><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 moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net"
target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<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><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<br>
</body>
</html>