<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Arial">thanks, perfect<br>
<br>
</font>
<div class="moz-cite-prefix">On 2/14/14, 10:29 AM, John Bradley
wrote:<br>
</div>
<blockquote
cite="mid:2C62D68F-E9D9-4F55-8A47-EE5B2BC2862A@ve7jtb.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>