<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><div style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">Hi John,</div><div style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "><br></div><div style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">even if this is not your idea, I would like to thank you for analyzing and explaining it so clearly.</div><div style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "><br></div><div style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">@Breno: Would you be so kind to shed some more light on the way Google envisions this federated login use case to work? I would especially like to understand how the audiences in the id token are determined and impact this feature has on the trust management among the involved parties.</div><div style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "><br></div><div style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">Best regards,</div><div style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">Torsten.</div><br>Am 27.12.2012 um 21:00 schrieb John Bradley <<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>>:<br><br></div><div><span></span></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=us-ascii">I am not saying using the id_token as a access token is a good idea, but people may do it anyway.<div><br></div><div>The difference is that the RS and Are not tightly coupled. The AS may not know anything more about the relationship between the client and the RS other than it allowed some linked registration.</div><div><br></div><div>The flow should be that the client has it's own AS and chains that back to a openID connect authentication.</div><div><br></div><div>However it seems from feedback that Google and others are given that developers don't like that as it has too many redirects.</div><div><br></div><div>They want to have the client do openID connect directly to google (perhaps through the Play API) and then pass a structured assertion to the AS for the RS or use the id_token directly at the RS.</div><div><br></div><div>This is not my idea so I am probably not the best one to be representing it.</div><div><br></div><div>It is however a way of doing federated OAuth where you have a native App and a server sharing a federated login state.</div><div><br></div><div>John B.</div><div><br><div><div>On 2012-12-27, at 4:28 PM, Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div dir="auto"><div>So the id token is essentially also becoming an access token? </div><div><br></div><div>How is it different from the access token the client also obtains from the OP? Especially, if the additional audiences shall be requested using scope values. </div><div><br></div><div>Let's assume the following: "openid myserver1 myserver2"</div><div><br></div><div>Would the OP add myserver1 and myserver2 to both tokens?</div><div><br></div><div>regards,</div><div>Torsten.</div><div><br>Am 27.12.2012 um 18:49 schrieb John Bradley <<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>>:<br><br></div><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1">The audiences would be determined by the Authorization server policy and perhaps indicated by the client via scopes.<div><br></div><div>So one thing would be to have the audience of the AS to use the ID token in the assertion flow now that we are changing user_id to match JWT.</div><div><br></div><div>The other is some set of related clients.</div><div><br></div><div>A client with a related server might register itself as having two client ID. </div><div><br></div><div>When the native app portion requests a login it gets back a id token that contains bot itself and the related server as the audiences.</div><div>The client could then use the assertion flow to exchange the id_token for a access token at the related service. </div><div><br></div><div>This is a sort of federated login for apps. People do this a bunch of insecure ways now.</div><div><br></div><div>However if I have an app that hat relies on Google or some other OIDC provider for authentication, I need some safe way of passing that authentication to my AS.</div><div>(Some clients will just pass the id_token directly as a access token though I don't think that is an especially good idea.)</div><div><br></div><div>So yes I can see an AS as an additional audience, it however may be one associated with the client and not the OIDC provider.</div><div><br></div><div>John B.</div><div><br></div><div><div><div>On 2012-12-27, at 2:12 PM, Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div text="#000000" bgcolor="#FFFFFF">
I agree with you for the general JWT case, esp. for multi-audience
access tokens. <br>
<br>
What are examples of multiple audiences in id tokens? Given the
original posting, I assume this might be the client_id and
additionally the authorization server itself. This would allow the
client to use this token in the assertion flow. How is the client
supposed to control the audiences to be included? Or is this
determined by the authorization server's policy?<br>
<br>
regards,<br>
Torsten.<br>
<br>
Am 27.12.2012 15:18, schrieb John Bradley:<br>
<blockquote cite="mid:D41E5EC0-5E44-4DB7-97A9-42A52C7489B5@ve7jtb.com" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
I don't think that having multiple audiences for JWT is a bad
thing as long as the recipients know what is going on.
<div><br>
</div>
<div>If we put it in the spec then people with closely related RS
or multi part clients can use it safely. </div>
<div>We can also include advice that if you get a multi audience
bearer token it could be coming from any party listed in the
audience as well as the AS.</div>
<div><br>
</div>
<div>I am more comfortable discussing the issues and saying when a
multi-audiance token may not be appropriate, vs people going
around the spec not understanding the issues.</div>
<div><br>
</div>
<div>John B.<br>
<div>
<div>On 2012-12-27, at 4:52 AM, Torsten Lodderstedt <<a moz-do-not-send="true" href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<div dir="auto">
<div>Isn't the obvious alternative to have different
tokens with each having a single audience value? It
would at least prevent token abuse by resource servers
(w/o proof of posession).</div>
<div><br>
</div>
<div>Regards,</div>
<div>Torsten.<br>
<br>
Am 20.12.2012 um 15:29 schrieb John Bradley <<a moz-do-not-send="true" href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>>:<br>
<br>
</div>
<blockquote type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
Yes if we have multiple audiences then who the token is
issued to is probably only useful if there is some sort
of proof of possession to go along with that.
<div><br>
</div>
<div>Google's use-case for cid could probably be solved
with multiple audiences, rather than cid as they are
not doing any proof of possession.</div>
<div><br>
</div>
<div>The thing is that is you receive a token with
multiple audiences then you need to assume that any of
the parties listed as a audience might have sent it to
you.</div>
<div><br>
</div>
<div>I think that is a easier security concept for most
people to get there heads around than thinking cid is
special somehow without proof of possession.</div>
<div><br>
</div>
<div>So I suspect in the end we need multiple audiences
and a way of doing proof of possession. They are
interrelated but not the same.</div>
<div><br>
</div>
<div>John</div>
<div>
<div>
<div>On 2012-12-20, at 10:50 AM, Brian Campbell <<a moz-do-not-send="true" href="mailto:bcampbell@pingidentity.com">bcampbell@pingidentity.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr">
<div>Without some additional authentication or
proof, I don't see what "cid" really
provides? <br>
<br>
</div>
<div>My intent only went as far as getting
support for multiple audiences into the base
JWT spec so there's some flexibility for other
types of token exchange use case. I get that
it might have implications in Connect but I
don't know if they need to be codified yet.<br>
<br>
</div>
<div>And, at the risk of picking another fight
with the gentlemen from Google, I'm not yet
convinced that what they've done with "cid" as
some kind of intermediate audience claim is
something that should be standardized. <br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Tue, Dec 18, 2012 at
6:17 PM, John Bradley <span dir="ltr"><<a moz-do-not-send="true" href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">If we were to
allow multiple audiences in a OIDC id_token
it raises the question of how a client
requests additional audiences and what it
means to a client that receives a id token
from that contains multiple audiences.<br>
There are also UI issues to consider around
what consent the user is asked for.<br>
<br>
This overlaps with the google use case
where the requester is identified in a
separate claim.<br>
<br>
It may be a useful thing to indicate the
actual requester of the JWT when there are
multiple audiences.<br>
<br>
Allowing for a client to get a token that
can be presented as part of an implicit flow
to a third party with them as the audience
opens up a security hole.<br>
<br>
I would be OK if we allow multiple audiences
in the ID_token where the client ID of the
requester is identified, as long as we do
not allow tokens with multiple audiences in
the implicit flow.<br>
<br>
So the normal case would be aud as a literal
and the 'cid' is implicitly the same as
'aud'.<br>
<br>
If 'aud' and 'cid' differ then the 'aud' is
an array of one or more values, and cid is
the identifier of the token requestor.<br>
<br>
Then the id_token could be used in an
assertion flow though I would prefer that
cid have some linking to the client making
the assertion flow request. perhaps there
is a way to do that using a proof of
possession key.<br>
<br>
Without proof of possession it is not really
any worse than a single AS with multiple RS
via scopes. The UI at the authorization
server is the hardest part.<br>
<br>
You are being asked to grant client X a
assertion granting it permission to access
service y on host foo.<br>
<br>
The id_token probably needs to contain some
sort of scope info for the target AS to make
a decision on.<br>
<br>
From a engineering perspective I like it.
From an explaining it perspective it
complicates things.<br>
<br>
John B.<br>
<div class="HOEnZb">
<div class="h5"><br>
<br>
<br>
On 2012-12-18, at 9:01 PM, Brian
Campbell <<a moz-do-not-send="true" href="mailto:bcampbell@pingidentity.com">bcampbell@pingidentity.com</a>>
wrote:<br>
<br>
> BTW Justin, I got focused on other
aspect of all this and forgot that<br>
> I wanted to ask you what (assuming
aud and prn/sub/who/etc work out)<br>
> this exchange actually looked like?
The JWT Assertion is designed for<br>
> the case of trading a JWT for an
access token but it sounds like you<br>
> are using it to get an id token? Is
that in place of the access token<br>
> or does it supplement it? Do you
send an openid scope in the request?<br>
> Just curious really...<br>
><br>
> On Fri, Dec 14, 2012 at 3:40 PM,
Justin Richer <<a moz-do-not-send="true" href="mailto:jricher@mitre.org">jricher@mitre.org</a>>
wrote:<br>
>> You are correct. I hadn't
caught that, but it does state in JWT
Assertions:<br>
>><br>
>> The JWT MUST contain an aud
(audience) claim containing a URI
reference that<br>
>> identifies the authorization
server, or the service provider
principal<br>
>> entity of its controlling
domain, as an intended audience. The
token<br>
>> endpoint URL of the
authorization server MAY be used as an
acceptable value<br>
>> for an aud element. The
authorization server MUST verify that it
is an<br>
>> intended audience for the JWT.<br>
>><br>
>><br>
>> Which doesn't leave much wiggle
room for the OIDC interpretation.
Between<br>
>> this an 'prn', maybe this is a
different kind of assertion claim, then?
An<br>
>> id-token assertion grant type?<br>
>><br>
>> -- Justin<br>
>><br>
>><br>
>> On 12/14/2012 04:51 PM, Brian
Campbell wrote:<br>
>><br>
>> I believe the current wording
of the specs would prohibit that.<br>
>><br>
>><br>
>><br>
>><br>
>> On Fri, Dec 14, 2012 at 2:10
PM, Justin Richer <<a moz-do-not-send="true" href="mailto:jricher@mitre.org">jricher@mitre.org</a>>
wrote:<br>
>>><br>
>>> My original idea is for the
Client to use the JWT Assertion flow
with a<br>
>>> current id_token to refresh
it and get a new id_token. This goes
back to the<br>
>>> session management proposal
linked to within the issue. In this
case, the<br>
>>> audience for the token
really *is* the client, and an AS will
need to look<br>
>>> for that.<br>
>>><br>
>>> -- Justin<br>
>>><br>
>>><br>
>>> On 12/14/2012 04:04 PM,
Brian Campbell wrote:<br>
>>><br>
>>> I had a comment/question
related to the below comment on issue
687 but not<br>
>>> really related to the issue
itself. So figured the list would be the
best<br>
>>> forum.<br>
>>><br>
>>> Regarding the potential use
of an ID Token as an assertion in the
OAuth<br>
>>> JWT Assertion Profile -
aren't the requirements around the "aud"
claim also<br>
>>> potentially a problem?<br>
>>><br>
>>> Connect says the aud of an
ID Token "MUST be the OAuth 2.0
client_id of<br>
>>> the Client." While the
OAuth JWT Assertion Profile is a little
more flexible<br>
>>> but basically says the aud
must identify the AS or its controlling
entity.<br>
>>> Doesn't this imply that an
ID Token could only really be used to
get an<br>
>>> access token within the
scope of the client to whom it was sent
in the first<br>
>>> place? Which doesn't seem
very useful. Or is it?<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> On Thu, Dec 13, 2012 at
5:23 PM, Michael Jones<br>
>>> <<a moz-do-not-send="true" href="mailto:issues-reply@bitbucket.org">issues-reply@bitbucket.org</a>>
wrote:<br>
>>>><br>
>>>> --- you can reply above
this line ---<br>
>>>><br>
>>>> Issue 687: Messages -
Add 'prn' claim to id_token to support
JWT<br>
>>>> Assertion<br>
>>>><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>
>>>> Michael Jones:<br>
>>>><br>
>>>><br>
>>>> I agree that it would
be a shame, architecturally, if we can't
use an ID<br>
>>>> Token as a assertion in
a way that complies with the OAuth JWT
Assertion<br>
>>>> Profile. 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<br>
>>>> space through
duplication of data; potential interop
problem where not<br>
>>>> everyone duplicates or
uses the information in the same way.<br>
>>>><br>
>>>> 2. Replace "user_id"
with "prn" in the ID Token. Downside:
Less<br>
>>>> mnemonic than user_id.
Upside: simple.<br>
>>>><br>
>>>> 3. Modify the OAuth
JWT Assertion Profile to allow the
subject to be<br>
>>>> identified by a claim
other than "prn" - possibly explicitly
calling out<br>
>>>> "user_id". Upside:
would work. Downside: Codifies
inconsistency.<br>
>>>><br>
>>>> 4. Replace both
"user_id" and "prn" with a different
claim in both<br>
>>>> specs. Candidates
include "id" and "sub".<br>
>>>><br>
>>>> Let's make this a topic
for Monday's call.<br>
>>>><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>
>>><br>
>>><br>
>>><br>
>>><br>
>>>
_______________________________________________<br>
>>> Openid-specs-ab mailing
list<br>
>>> <a moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net">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>
>>><br>
>><br>
>><br>
>
_______________________________________________<br>
> Openid-specs-ab mailing list<br>
> <a moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net">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>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<blockquote type="cite"><span>_______________________________________________</span><br>
<span>Openid-specs-ab mailing list</span><br>
<span><a moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a></span><br>
<span><a moz-do-not-send="true" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span><br>
</blockquote>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</blockquote></div><br></div></blockquote></div></blockquote></div><br></div></div></blockquote></body></html>