<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Arial">thanks John, so the Token EP would know to return
an (appropriately targetted) id_token rather than an access token
based on the scope?<br>
<br>
what parts remain to be spec'd out?<br>
<br>
1) the refresh call from TA is unchanged correct?<br>
2) the returned id_token ?<br>
3) the JWT assertion exchange?<br>
<br>
paul<br>
<br>
</font>
<div class="moz-cite-prefix">On 2/13/14, 11:19 AM, John Bradley
wrote:<br>
</div>
<blockquote
cite="mid:720C6DBE-A8C3-4A09-B066-4AB9FD76904A@ve7jtb.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div>This shows using the token endpoint to side-scope a refresh
token to get a id_token with a 3rd party audience using the
Google Play example, then using the JWT assertion flow to
exchange the id_token for a access token.</div>
<div><br>
</div>
<div>This is the Google developer spec for the Play Method <a
moz-do-not-send="true"
href="http://android-developers.blogspot.com/2013/01/verifying-back-end-calls-from-android.html">http://android-developers.blogspot.com/2013/01/verifying-back-end-calls-from-android.html</a></div>
<div>They don't have there Token Agent do the swap for a access
token, they are handing the id_token to the app and letting it
use it as an access token or exchange it in some way.</div>
<div><br>
</div>
<div>The other possibility may be to have the Appinfo endpoint
return the id_token along with meta-data about what 3rd party
Token endpoint needs to be used to exchange the id_token/JWT
assertion.</div>
<div>This may work better if the Token Agent is doing the exchange
rather than the app.</div>
<div><br>
</div>
<div><br>
</div>
<div>For those not part of the Connect WG we deliberately the
id_token the same format as a JWT for use in assertions. </div>
<div><br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<div>
<div>On Feb 12, 2014, at 6:20 PM, 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">guys,
care to swimlane that model out at websequencediagrams?<br>
<br>
paul<br>
</font>
<div class="moz-cite-prefix">On 2/12/14, 3:52 PM, Chuck
Mortimore wrote:<br>
</div>
<blockquote
cite="mid:CA+wnMn99U-vONCOJQRy+EMtk27bQug0_LV0jWuVvWzHx25r-VQ@mail.gmail.com"
type="cite">
<div dir="ltr">We've been thinking of a model where the RS
could validate the id_token for access to it's services
and exchange it via assertion flow if it needed to act
on behalf of user at the RS associated with the original
AS. This sounds inline with that
<div> <br>
</div>
<div>-cmort</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Feb 12, 2014 at 12:39
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">
<div style="word-wrap:break-word">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>
<div class="h5">
<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" target="_blank">cmortimore@salesforce.com</a>>
wrote:</div>
<br>
<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">
<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>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>
<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"
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>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</blockquote>
<br>
</body>
</html>