<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;"><div>For discussion for today's call</div><div><br></div>Inline<div><br><div><div>On Feb 5, 2014, at 8:58 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"><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></blockquote><div><br></div>We need to discuss this. A Token Agent has the equivalent to super-user status. However I can see not necessarily wanting to have a separate client_id for each client instance.</div><div>There may be some compromise that can make this a SHOULD and perhaps use a proof of possession mechanism for the refresh token. We have that for code in <a href="http://www.ietf.org/id/draft-sakimura-oauth-tcse-02.txt">http://www.ietf.org/id/draft-sakimura-oauth-tcse-02.txt</a> perhaps that could be extended to refresh. </div><div><br></div><div><blockquote type="cite"><div dir="ltr"><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></blockquote><div><br></div>Now that the connect spec is final we could replace 7.1 with"</div><div><br></div><div>The Token Agent performs Authorization per Sec 3.1 or Sec 3.3 of OpenID Connect Core.</div><div>The "scope" parameter sent to the Authorization server in Sec 3.1.2.1 MUST contain the space separated scope "AZA" in addition to andy other scopes requested.</div><div><br></div><div><br><blockquote type="cite"><div dir="ltr">
<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></blockquote><div><br></div><div>It is a carry over from being originally based on the base OAuth RFC without the hybrid flows. I don't know that there is a use case for pure implicit with a native client.</div><div><br></div><div>I am assuming that there must be a way to do the JS callback to extract the fragment and POST it to the app. If it works we probably shouldn't exclude the option.</div><div><br></div><div>We also have response_mode now to specify a Form post option that might work better for native apps.</div><br><blockquote type="cite"><div dir="ltr"><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></blockquote><br><div>We have a number of options in the case of User Consent.</div><div>1: The token Agent could collect consent based on info gathered from the AppInfo endpoint.</div><div>2: If the AS requires additional consent we could do a front channel authorization with prompt=consent&response_type=none (though this will likely for the user to authenticate to the AS)</div><div><br></div><div>I think the value would be in having the Token Agent collect consent like the Google Play agent is doing.</div><div><br></div><div><br></div><br><blockquote type="cite"><div dir="ltr"><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></blockquote><div><br></div>My comments above apply<br><blockquote type="cite"><div dir="ltr"><div> </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></blockquote><div><br></div>The goal is to have specific interactions for the different environments.<br><blockquote type="cite"><div dir="ltr">
<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></blockquote><div><br></div>We can wish can't we:) I agree that on iOS outside of a MDM environment this is a real problem in the TA initiated flow.<br><blockquote type="cite"><div dir="ltr">
<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></blockquote>This is a similar problem to <a href="http://www.ietf.org/id/draft-sakimura-oauth-tcse-02.txt">http://www.ietf.org/id/draft-sakimura-oauth-tcse-02.txt</a> however we have the problem of the channel potentially being hijacked in both directions.</div><div>It may be that returning the token in a JWE or using proof of possession access tokens are the only options in insecure environments.</div><div><br></div><div>There is a interesting question that will need to be considered in the OAuth PoP spec. Normally in OAuth it would be the client using the AT that is requesting it from the Token Endpoint and capable of proving possession of the private key. In the TA case we may have two entities with private keys one for the end client and one for the TA. The TA may need to send some challenge to the end client and validate the response before including the public key in the request to the token endpoint. Something we will need to think about in that spec.<br><div><br></div><br><blockquote type="cite"><div dir="ltr"><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">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>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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 class="HOEnZb"><font color="#888888"><br>
<br>
Paul<br>
</font></span></font>
</div>
<br>_______________________________________________<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>
<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>
_______________________________________________<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>