<div dir="ltr">Nat's spec is less applicable when you have a AZA. I was providing a more generalized response on how to protect the URL scheme mechanism. Nat's spec would be useful if you were simply leaving a single app for authentication and expecting a callback. The public key method might work better with an AZA, although the introduction of the AZA probably leaves some soft of MITM vector if it's being addressed with a custom scheme</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 4, 2014 at 3:45 AM, 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 size="+1"><font face="Arial">trying to understand where Nat's
spec fits here. <br>
<br>
The TCSE</font></font><font size="+1"><font face="Arial"><font size="+1"><font face="Arial"> spec requires an two-stage
code-style flow as opposed to a single-stage implicit-style
flow<br>
<br>
</font></font>As I see it, there are logically two
client-server interactions here <br>
<br>
1) that between app & TA (nee AZA) <br>
2) that between the TA and the AS <br>
<br>
Both could theoretically be either code or indirect style
(though #2 will be code so we don't rule out TA authentication
to the AS)<br>
<br>
So we end up with the following permutations<br>
<br>
<b>1) Implicit & implicit</b><br>
<br>
AS TA App<br>
<--- request ----<br>
<---- request -----<br>
------- token ------><br>
----- token -----><br>
<br>
<b>2) Implicit & Code</b><br>
</font></font><br>
<font size="+1"><font face="Arial"><font size="+1"><font face="Arial">AS TA App<br>
<--- request ----<br>
<---- request -----<br>
-------- code ------><br>
<------ code -------<br>
------- token ------><br>
----- token -----><br>
</font></font></font></font><br>
<font size="+1"><font face="Arial"><font size="+1"><font face="Arial"><font size="+1"><font face="Arial"><b>3) Code</b><b>
& implicit </b><br>
</font></font><br>
<font size="+1"><font face="Arial"><font size="+1"><font face="Arial">AS TA
App<br>
<--- request ----<br>
<---- request -----<br>
------- token ------><br>
------ code -----><br>
<---- code ------<br>
----- token -----><br>
</font></font></font></font></font></font></font></font><br>
<font size="+1"><font face="Arial"><font size="+1"><font face="Arial"><font size="+1"><font face="Arial"><font size="+1"><font face="Arial"><font size="+1"><font face="Arial"><b>4</b><b>) Code & Code</b><br>
</font></font><br>
<font size="+1"><font face="Arial"><font size="+1"><font face="Arial">AS TA
App<br>
<--- request
----<br>
<---- request -----<br>
-------- code ------><br>
<------ code -------<br>
------- token ------></font></font></font></font></font></font></font></font></font></font></font></font><br>
<font size="+1"><font face="Arial"><font size="+1"><font face="Arial"><font size="+1"><font face="Arial"><font size="+1"><font face="Arial"><font size="+1"><font face="Arial"><font size="+1"><font face="Arial"><font size="+1"><font face="Arial"><font size="+1"><font face="Arial"><font size="+1"><font face="Arial"><font size="+1"><font face="Arial">
------ code -----><br>
<---- code ------<br>
</font></font></font></font></font></font></font></font>
----- token -----><br>
<br>
TCSE could protect against an attacker app,
having squatted on the custom URL of the
legit app, stealing the code returned by the
TA in Options #3 & #4 above.<br>
<br>
TCSE does not apply in an 'IdP init' model
where the application is launched from a UI
provided by the TA.<span class="HOEnZb"><font color="#888888"><br>
<br>
</font></span></font></font></font></font></font></font></font></font></font></font><span class="HOEnZb"><font color="#888888">paul<br>
<br>
</font></span></font></font><div><div class="h5">
<div>On 6/3/14, 12:03 PM, Chuck Mortimore
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Did some work on this at Salesforce over the last
couple weeks.
<div><br>
</div>
<div>When calling aza, on iOS the app is able to determine
calling app identity by an injected bundle id. On Android you
can get a cert hash. Both are OS asserted so are relatively
secure assuming a non-jailbroken device. There doesn't
seem, at least on iOS, to be a good way from preventing
hijacking of the aza's custom scheme, so this is likely
susceptible to at least some sort of phishing</div>
<div><br>
</div>
<div>As far as callbacks back into the requesting app, we've
looked at two approaches. Either Nat's <a href="http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03" target="_blank">http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03</a>
as well as issuing an ephemeral public/private key, passing
the public key in the request, and encrypting the response.
Both seem to work well enough for protection against hijacked
callbacks. At this point, we're heading towards the former
given the relative simplicity. </div>
<div><br>
</div>
<div>-cmort</div>
<div><br>
</div>
<div> </div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Tue, Jun 3, 2014 at 8:18 AM,
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>
<div>Writ the URL scheme mechanism, has anybody done the
exercise of assessing the associated security
characteristics in Android and iOS?</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div style="font-size:8px;color:#575757">Sent from my
Samsung Galaxy smartphone.</div>
</div>
<br>
<br>
-------- Original message --------<br>
From: Lloyd Burch <br>
Date:06-03-2014 11:00 AM (GMT-05:00) <br>
To: <a href="mailto:paul.madsen@gmail.com" target="_blank">paul.madsen@gmail.com</a>,
<a href="mailto:openid-specs-native-apps@lists.openid.net" target="_blank">openid-specs-native-apps@lists.openid.net</a>
<br>
Subject: Re: [Openid-specs-native-apps] IOS 8 interapp
messaging <br>
<br>
<div>
<div>I have now watched it three time and am looking for
more information on the details. </div>
<div> </div>
<div>What I would like to know is, can the called and
calling application know the ID of each other and can
that be validated via iOS?</div>
<div> </div>
<div>Using the URL Schema calls is a little SLOW, but it
is all we have now. This should fix this.</div>
<div> </div>
<div>Lloyd </div>
<span> </span>
<div><span><br>
<br>
>>> Paul Madsen <<a href="mailto:paul.madsen@gmail.com" target="_blank">paul.madsen@gmail.com</a>>
6/2/2014 1:42 PM >>><br>
</span>
<div>
<div><span style="background-color:rgb(255,255,255)" text="#000000" bgcolor="#FFFFFF">> <font size="+1"><font face="Arial"><a href="http://www.theverge.com/2014/6/2/5773080/ios-8-apps-can-talk-to-each-other" target="_blank">http://www.theverge.com/2014/6/2/5773080/ios-8-apps-can-talk-to-each-other</a></font></font></span></div>
<div><font size="+1"><font face="Arial"> </font></font></div>
<div><font size="+1"><font face="Arial"> perhaps
relevant to mobile binding spec</font></font></div>
<div><font size="+1"><font face="Arial"> </font></font></div>
<div><font size="+1"><font face="Arial"> paul</font></font></div>
<div><font size="+1"><font face="Arial"> </font></font>
</div>
</div>
</div>
</div>
</div>
<br>
_______________________________________________<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>
<br>
</div></div></div>
</blockquote></div><br></div>