<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;">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 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 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 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 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 href="mailto:Openid-specs-native-apps@lists.openid.net" target="_blank">Openid-specs-native-apps@lists.openid.net</a><br>
<a 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 href="mailto:Openid-specs-native-apps@lists.openid.net">Openid-specs-native-apps@lists.openid.net</a><br>http://lists.openid.net/mailman/listinfo/openid-specs-native-apps<br></blockquote></div><br></div></body></html>