<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
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<br>
<br>
<div class="moz-cite-prefix">On 12/17/2012 07:52 AM, Brian Campbell
wrote:<br>
</div>
<blockquote
cite="mid:CA+k3eCQKHsKk_0ePiKLkFcz=CYOFd9zeme6TSW2QO6ZBpkYU+Q@mail.gmail.com"
type="cite">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>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Sat, Dec 15, 2012 at 1:53 PM, Dale
Olds <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:olds@vmware.com" target="_blank">olds@vmware.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>
<blockquote type="cite">Somewhat tangentally though is
that JWT only allows for a single audience to be
identified in the token.</blockquote>
<br>
</div>
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><font color="#888888"><br>
<br>
--Dale</font></span>
<div>
<div><br>
<br>
<br>
<div>On 12/14/2012 03:11 PM, Brian Campbell wrote:<br>
</div>
<blockquote 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><font
color="#888888"><br>
<br>
-- Justin</font></span>
<div>
<div><br>
<br>
On 12/14/2012 04:51 PM, Brian Campbell
wrote:<br>
</div>
</div>
</div>
<div>
<div>
<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></fieldset>
<br>
<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>
</div>
</div>
<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><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>