<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">The connect spec was modified to allow for it but it is not explicitly called out anyplace as how you do 3rd party id_tokens.<div><br></div><div><br></div><div>In <a href="http://openid.net/specs/openid-connect-core-1_0.html#IDToken">Core Sec 2</a></div><div>We modified "aud" from a single value to an array:</div><div><dt style="font-family: verdana, charcoal, helvetica, arial, sans-serif; font-size: small; background-color: rgb(255, 255, 255);">aud</dt><dd style="font-family: verdana, charcoal, helvetica, arial, sans-serif; font-size: small; background-color: rgb(255, 255, 255);">REQUIRED. Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 <tt style="color: rgb(0, 51, 102); font-family: 'Courier New', Courier, monospace;">client_id</tt> of the Relying Party as an audience value. It MAY also contain identifiers for other audiences. In the general case, the <tt style="color: rgb(0, 51, 102); font-family: 'Courier New', Courier, monospace;">aud</tt> value is an array of case sensitive strings. In the common special case when there is one audience, the <tt style="color: rgb(0, 51, 102); font-family: 'Courier New', Courier, monospace;">aud</tt> value MAY be a single case sensitive string.</dd><div><br></div><div>We added "azp" to identify the party to whom the token was issued:</div><div><br></div><div><dt style="font-family: verdana, charcoal, helvetica, arial, sans-serif; font-size: small; background-color: rgb(255, 255, 255);">azp</dt><dd style="font-family: verdana, charcoal, helvetica, arial, sans-serif; font-size: small; background-color: rgb(255, 255, 255);">OPTIONAL. Authorized party - the party to which the ID Token was issued. If present, it MUST contain the OAuth 2.0 Client ID of this party. This Claim is only needed when the ID Token has a single audience value and that audience is different than the authorized party. It MAY be included even when the authorized party is the same as the sole audience. The <tt style="color: rgb(0, 51, 102); font-family: 'Courier New', Courier, monospace;">azp</tt> value is a case sensitive string containing a StringOrURI value.</dd><div><br></div></div><div>That way an id_token can identify who issued it "iss", to what client was it issued "azp" and who are the valid audiences.</div><div><br></div><div><br></div><div>In <a href="http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation">Core Sec 3.1.3.7</a> for id_token validation by a client the rules state:</div><div><br></div><div><ol class="text" style="margin-left: 2em; margin-right: 2em; font-family: verdana, charcoal, helvetica, arial, sans-serif; font-size: small;"><li style="margin-left: 3em;">The Client MUST validate that the <tt style="color: rgb(0, 51, 102); font-family: 'Courier New', Courier, monospace;">aud</tt> (audience) Claim contains its <tt style="color: rgb(0, 51, 102); font-family: 'Courier New', Courier, monospace;">client_id</tt> value registered at the Issuer identified by the <tt style="color: rgb(0, 51, 102); font-family: 'Courier New', Courier, monospace;">iss</tt> (issuer) Claim as an audience. The <tt style="color: rgb(0, 51, 102); font-family: 'Courier New', Courier, monospace;">aud</tt> (audience) Claim MAY contain an array with more than one element. The ID Token MUST be rejected if the ID Token does not list the Client as a valid audience, or if it contains additional audiences not trusted by the Client.</li><li style="margin-left: 3em;">If the ID Token contains multiple audiences, the Client SHOULD verify that an <tt style="color: rgb(0, 51, 102); font-family: 'Courier New', Courier, monospace;">azp</tt> Claim is present.</li><li style="margin-left: 3em;">If an <tt style="color: rgb(0, 51, 102); font-family: 'Courier New', Courier, monospace;">azp</tt> (authorized party) Claim is present, the Client SHOULD verify that its <tt style="color: rgb(0, 51, 102); font-family: 'Courier New', Courier, monospace;">client_id</tt> is the Claim Value.</li></ol><div><br></div></div><div>We also took out a prohibition on returning a id_token from the token endpoint in response to a "refresh_token" grant_type.</div><div><br></div><div>Google presented the use case for third party id_tokens relatively late in the process, so we allowed for them to be fully defined in an extension like napps. </div><div>The important thing we did was include the processing rule about multiple audiences and "azp" in the core spec so that clients who don't know about third party id_tokens won't blindly accept them if they have someone else as the "azp" even if they are one of the audiences. </div><div><br></div><div>That's why the Connect spec is silent on how to request them and all of the possible additional semantics.</div><div><br></div><div>I think it is up to us to define the missing parts.</div><div><br></div><div>John B.</div><div><br><div><div>On Feb 14, 2014, at 11:26 AM, Paul Madsen <<a href="mailto:paul.madsen@gmail.com">paul.madsen@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
<font face="Arial">John, can you point me to the relevant piece of
Connect that enables these 3rd party id_tokens?<br>
<br>
thanks<br>
<br>
paul<br>
</font>
<div class="moz-cite-prefix">On 2/12/14, 3:39 PM, John Bradley
wrote:<br>
</div>
<blockquote cite="mid:F4BBB6DA-65DB-4554-AE17-5355BFC309BF@ve7jtb.com" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
Hi Chuck,
<div><br>
</div>
<div>I will get to this over the next couple of days. </div>
<div><br>
</div>
<div>We do have the 3rd party id_tokens that can be used as JWT
assertions that were added to connect for Google. In principal
those should be exchanged in the assertion flow for access
tokens when crossing security domains.</div>
<div><br>
</div>
<div>So I suppose the type of token would depend on if the app
directly accepted access tokens from the AS of the napps agent.</div>
<div><br>
</div>
<div>Apps using Google Play services directly use the id_token as
a access token in general but that places a potential burden on
the RS to accept tokens of different types. I prefer to use
the token endpoint to exchange the assertion so the RS only
needs to worry about access tokens from it's AS whatever those
happen to be.</div>
<div><br>
</div>
<div>John B.</div>
<div><br>
</div>
<div>
<div>
<div>On Feb 5, 2014, at 11:48 PM, Chuck Mortimore <<a moz-do-not-send="true" href="mailto:cmortimore@salesforce.com">cmortimore@salesforce.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr">One other thought - Perhaps instead of
opaque access tokens for the apps, we should issue
id_tokens that are audience restricted </div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Feb 5, 2014 at 3:58 PM,
Chuck Mortimore <span dir="ltr"><<a moz-do-not-send="true" href="mailto:cmortimore@salesforce.com" target="_blank">cmortimore@salesforce.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0px 0px
0px 0.8ex; border-left-width: 1px; border-left-color:
rgb(204, 204, 204); border-left-style: solid;
padding-left: 1ex; position: static; z-index: auto;">
<div dir="ltr">
<div><b>Comments on Agent Core 1.0</b></div>
<div><br>
</div>
<div>5.0 - Do we need to make client credentials
mandatory? Can we make this a MAY?</div>
<div><br>
</div>
<div>7.1 - in general seems redundant to
oauth/openid connect, with the exception of the
AZA scope. Do we need to respecify all of this?</div>
<div><br>
</div>
<div>7.1.1 - Why is response_type=code MUST? Is
this oauth carry over? (same as my question on
5.0 I think)</div>
<div><br>
</div>
<div>7.4.1/2 - By issuing on the token endpoint, we
are basically saying that only administrative
authorization models will work. If end-user
authorized oauth is being used, the user doesn't
have a chance to approve access to and new app.
Shouldn't we be performing a new Authorization
request, rather than a straight refresh token
exchange?</div>
<div><br>
</div>
<div><br>
</div>
<div><b>Comments on Agent API bindings 1.0</b></div>
<div><br>
</div>
<div>2.0 - "Rather than the user individually
authenticating and authorizing each native
application, they do so only for the authorization
agent" - same as my last comment; from an
authorization model perspective, this basically
kills off end-user approval models with this
profile. There's no way for the user to make
effective authorization decisions for future
unknown applications. </div>
<div><br>
</div>
<div>4.0 - this seems to really be the meat of what
we should specify, but the entire section is
basically silent on detail. For this spec to be
successful, shouldn't we take a stand and actually
specify interaction patterns?</div>
<div><br>
</div>
<div>4.1 - "The TA MUST NOT deliver a secondary
access token to an application for which it was
not issued." seems at odds with the rest of this
section. For example, the custom scheme approach
would potentially violate this on iOS. I'm not
certain there is a reliable way not to violate
this when supporting an TA intiated flow.</div>
<div><br>
</div>
<div>4.2 - We should really spec out a Native App
intiated flow. It may be the only way we can
reliably handle the security contraint in section
4.1. One option could be to issue a public key
with the authorization request and then encrypt
the use JWE to responds, so if the Native app's
custom scheme url were hijacked, the returned
token wouldn't bleed to the wrong app.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">
<div>
<div class="h5">On Wed, Feb 5, 2014 at 1:18 PM,
Paul Madsen <span dir="ltr"><<a moz-do-not-send="true" href="mailto:paul.madsen@gmail.com" target="_blank">paul.madsen@gmail.com</a>></span>
wrote:<br>
</div>
</div>
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div>
<div class="h5">
<div bgcolor="#FFFFFF" text="#000000"> <font face="Arial">Both core & bindings
are available at<br>
<br>
<a moz-do-not-send="true" href="http://hg.openid.net/napps/wiki/Home" target="_blank">http://hg.openid.net/napps/wiki/Home</a><br>
<br>
John has some editorial fixes to make
but is hoping to combine with those with
any more normative changes<br>
<br>
Our next call is Wed feb 19 @ 6 pm EST<span><font color="#888888"><br>
<br>
Paul<br>
</font></span></font> </div>
<br>
</div>
</div>
_______________________________________________<br>
Openid-specs-native-apps mailing list<br>
<a moz-do-not-send="true" href="mailto:Openid-specs-native-apps@lists.openid.net" target="_blank">Openid-specs-native-apps@lists.openid.net</a><br>
<a moz-do-not-send="true" href="http://lists.openid.net/mailman/listinfo/openid-specs-native-apps" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-native-apps</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
<br>
</div>
_______________________________________________<br>
Openid-specs-native-apps mailing list<br>
<a moz-do-not-send="true" href="mailto:Openid-specs-native-apps@lists.openid.net">Openid-specs-native-apps@lists.openid.net</a><br>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-native-apps">http://lists.openid.net/mailman/listinfo/openid-specs-native-apps</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</blockquote></div><br></div></div></body></html>