[Openid-specs-native-apps] IOS 8 interapp messaging

Tue Jul 8 14:09:31 UTC 2014

I suppose there has been some follow ups here by now, but IMHO,
in as much as we can utilize OS asserted info through inter-app
communication, we should leverage it.

TCSE spec being just using symmetric PoP is due to Google feedback that
they had such a push back from the internal app developers for using public
key crypto version of it. If the developers creating one of the most famous
app available could not do it, the prospect looked pretty grim so we opted
to concentrate on the symmetric one. FYI, my preference is pub-key based
one though as some of you may have suspected.

2014-06-07 4:28 GMT+09:00 Chuck Mortimore <cmortimore at salesforce.com>:

> 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
>
>
> On Wed, Jun 4, 2014 at 3:45 AM, Paul Madsen <paul.madsen at gmail.com> wrote:
>
>>  trying to understand where Nat's spec fits here.
>>
>> The TCSE spec requires an two-stage code-style flow as opposed to a
>> single-stage implicit-style flow
>>
>> As I see it, there are logically two client-server interactions here
>>
>> 1) that between app & TA (nee AZA)
>> 2) that between the TA and the AS
>>
>> 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)
>>
>> So we end up with the following permutations
>>
>> *1) Implicit & implicit*
>>
>> AS                     TA                   App
>>                            <--- request ----
>>  <---- request -----
>> ------- token ------>
>>                             ----- token ----->
>>
>> *2) Implicit & Code*
>>
>> AS                     TA                   App
>>                            <--- request ----
>>  <---- request -----
>> -------- code ------>
>> <------ code -------
>> ------- token ------>
>>                             ----- token ----->
>>
>> *3) Code** & implicit *
>>
>> AS                     TA                   App
>>                            <--- request ----
>>  <---- request -----
>> ------- token ------>
>>                             ------ code ----->
>>                             <---- code ------
>>                             ----- token ----->
>>
>> *4**) Code & Code*
>>
>> AS                     TA                   App
>>                            <--- request ----
>>  <---- request -----
>> -------- code ------>
>> <------ code -------
>> ------- token ------>
>>                           ------ code ----->
>>                           <---- code ------
>>                           ----- token ----->
>>
>> 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.
>>
>> TCSE does not apply in an 'IdP init' model where the application is
>> launched from a UI provided by the TA.
>>
>> paul
>>
>>  On 6/3/14, 12:03 PM, Chuck Mortimore wrote:
>>
>> Did some work on this at Salesforce over the last couple weeks.
>>
>>  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
>>
>>  As far as callbacks back into the requesting app, we've looked at two
>> approaches.   Either Nat's
>> http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 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.
>>
>>  -cmort
>>
>>
>>
>>
>> On Tue, Jun 3, 2014 at 8:18 AM, Paul.madsen <paul.madsen at gmail.com>
>> wrote:
>>
>>>  Writ the URL scheme mechanism,  has anybody done the exercise of
>>> assessing the associated security characteristics in Android and iOS?
>>>
>>>
>>>  Sent from my Samsung Galaxy smartphone.
>>>
>>>
>>> -------- Original message --------
>>> From: Lloyd Burch
>>> Date:06-03-2014 11:00 AM (GMT-05:00)
>>> To: paul.madsen at gmail.com, openid-specs-native-apps at lists.openid.net
>>> Subject: Re: [Openid-specs-native-apps] IOS 8 interapp messaging
>>>
>>>  I have now watched it three time and am looking for more information
>>> on the details.
>>>
>>> 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?
>>>
>>> Using the URL Schema calls is a little SLOW, but it is all we have now.
>>> This should fix this.
>>>
>>> Lloyd
>>>
>>>
>>>
>>> >>> Paul Madsen <paul.madsen at gmail.com> 6/2/2014 1:42 PM >>>
>>>  >
>>> http://www.theverge.com/2014/6/2/5773080/ios-8-apps-can-talk-to-each-other
>>>   perhaps relevant to mobile binding spec
>>>   paul
>>>
>>> _______________________________________________
>>> Openid-specs-native-apps mailing list
>>> Openid-specs-native-apps at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-native-apps
>>>
>>>
>>
>>
>
> _______________________________________________
> Openid-specs-native-apps mailing list
> Openid-specs-native-apps at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-native-apps
>
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-native-apps/attachments/20140708/acfb3f69/attachment.html>