Hi, as you know the unified push server has a 'registration' component (see here <https://gist.github.com/matzew/69d33a18d4fac9fdedd4> for details; see here <https://gist.github.com/matzew/2da6fc349a4aaf629bce> for REST APIs) which does the following: - app registration and adding multiple variations - registration of an installation, submitted from the device There are different roles (as also discussed in the above links).... The "app registration" functionality can be only achieved by something *like* an "admin"; The admin can create a logical app construct on the server ( *Sport News mobile* ), which has different variations: - free for iOS/Android (no user required, everybody can install the app) - paid (same, for both: iOS/Android): User is required, since they pay for extra, exclusive content Now.... the "logical" app construct on the server get's some ID, when the app has been registered... (similar for each of the variants: iOS/iOS-paid etc...) This part of the registration needs to be protected, very well (e.g. OAuth); just thinking out loud.... But yeah... only users, with the proper rights should be able to register (update/delete) apps here!!! <https://gist.github.com/matzew/e335881b3f95b1448774#deviceinstallation-re... registration However, the other part of the registration (when an installation, from a device, tries to register itself for wanting to receive messages), may be a little more "weak"... Scenario: - Someone downloads the free iOS app: - once he launches the app and he agrees on receiving push messages - Now... the app should send the generated token (generated by the actual Push Network), to the registration server... (otherwise it can't receive push messages :-) ). So...... the following information needs to be available.... so that the mobile dev. for the free iOS app can register the token with the server: - APP ID (+ mobile-variant ID) Yes, the IDs are needed.... in order to tell the "registration server": *Hey, this installation for XYZ wants to receive messages.....* So, the iOS (client SDK) code could look like: - (void)application:(UIApplication *)applicationdidRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken{ NSURL *serverURL = [NSURL URLWithString:@"http://pusher.server.com/registry/device/"]; PushClient *pclient = [PushClient appID:@"1234" mobileID:@"456454"]; [pclient registerDeviceToken:deviceToken withServer:serverURL success:^(id responseObject) { NSLog(@"Registration Success: %@", responseObject); } failure:^(NSError *error) { NSLog(@"Registration Error: %@", error); }];} The code above would be used by some customer/user, when they register their app with their running version, of our Unified Push server..... Not sure.... are we concerned about the keys are compiled into the actual app, that everybody could download from the app store ?

We really can't issue a login in the above case, since there may be no user..... and even if the paid app, requires a user..... someone can still first buy the app, and after installation decide to register a new user, from the app...... so the above code is still executed BEFORE the user decides to active/register his account... Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf

On Tue, Apr 9, 2013 at 5:53 PM, Matthias Wessendorf <matzew(a)apache.org (mailto:matzew@apache.org)> wrote: > > > > On Tue, Apr 9, 2013 at 4:47 PM, Matthias Wessendorf <matzew(a)apache.org (mailto:matzew@apache.org)> wrote: > > > > Hi, > > > > > > as you know the unified push server has a 'registration' component (see here (https://gist.github.com/matzew/69d33a18d4fac9fdedd4) for details; see here (https://gist.github.com/matzew/2da6fc349a4aaf629bce) for REST APIs) which does the following: > > > > app registration and adding multiple variations > > registration of an installation, submitted from the device > > > > > > There are different roles (as also discussed in the above links).... The "app registration" functionality can be only achieved by something like an "admin"; > > > > > > The admin can create a logical app construct on the server ( Sport News mobile ), which has different variations: > > > > free for iOS/Android (no user required, everybody can install the app) > > paid (same, for both: iOS/Android): User is required, since they pay for extra, exclusive content > > > > > > Now.... the "logical" app construct on the server get's some ID, when the app has been registered... (similar for each of the variants: iOS/iOS-paid etc...) > > > > > > This part of the registration needs to be protected, very well (e.g. OAuth); just thinking out loud.... But yeah... only users, with the proper rights should be able to register (update/delete) apps here!!! > > > > Device/Installation registration > > > > However, the other part of the registration (when an installation, from a device, tries to register itself for wanting to receive messages), may be a little more "weak"... > > > > > > Scenario: > > > > Someone downloads the free iOS app: > > once he launches the app and he agrees on receiving push messages > > Now... the app should send the generated token (generated by the actual Push Network), to the registration server... (otherwise it can't receive push messages :-) ). > > > > > > So...... the following information needs to be available.... so that the mobile dev. for the free iOS app can register the token with the server: > > > > APP ID (+ mobile-variant ID) > > > > > > Yes, the IDs are needed.... in order to tell the "registration server": Hey, this installation for XYZ wants to receive messages..... > > > > > > So, the iOS (client SDK) code could look like: > > > > - (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken { NSURL *serverURL = [NSURL URLWithString:@"http://pusher.server.com/registry/device/"]; PushClient *pclient = [PushClient appID:@"1234" mobileID:@"456454"]; [pclient registerDeviceToken:deviceToken withServer:serverURL success:^(id responseObject) { NSLog(@"Registration Success: %@", responseObject); } failure:^(NSError *error) { NSLog(@"Registration Error: %@", error); }]; } > > > > > > The code above would be used by some customer/user, when they register their app with their running version, of our Unified Push server..... Not sure.... are we concerned about the keys are compiled into the actual app, that everybody could download from the app store ? > > > > Others do similar, requiring some sort of "API KEY" (similar to our appID/MobileID pair) being submitted when registering a specific device/installation. > > That said, without these IDs/Keys.... you can't register an app... perhaps this app/mobile app thing can be used + a "private key" (e.g. for the admin/developer....) and internally we issue some OAuth req., for the registration? I guess.... we should do/recommend some sort of encryption here.... since these keys are compiled into the app....... hrm... > > NOTE: the appID/mobileID keys are generated by our server, when an admin/developer creates the logical construct of an app, on the server... > > > > > > > We really can't issue a login in the above case, since there may be no user..... and even if the paid app, requires a user..... someone can still first buy the app, and after installation decide to register a new user, from the app...... so the above code is still executed BEFORE the user decides to active/register his account... > > > > > > Matthias > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org) https://lists.jboss.org/mailman/listinfo/aerogear-dev

Might be another topic, not sure. Did you get a chance to look at this https://github.com/argon/node-apn? -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile On Tuesday, April 9, 2013 at 2:32 PM, Bruno Oliveira wrote: > Hi Matthias, for the authentication method let me know if some of those workflows works for you https://developers.google.com/accounts/docs/OAuth2 ? > > For encryption I'm working on ECDH ( http://en.wikipedia.org/wiki/Elliptic_curve_Diffie%E2%80%93Hellman) but if you're in hurry we can stick with AES only (if you really want some encryption). > > I'll be working on a bare minimum crypto specification (suggestion) for the client side, but words don't compile. So I've been testing it before. > > > -- > "The measure of a man is what he does with power" - Plato > - > @abstractj > - > Volenti Nihil Difficile > > > > On Tuesday, April 9, 2013 at 1:20 PM, Matthias Wessendorf wrote: > > > > > > > > > On Tue, Apr 9, 2013 at 5:53 PM, Matthias Wessendorf <matzew(a)apache.org(mailto: matzew(a)apache.org)&gt; wrote: > > > > > > > > > > > > On Tue, Apr 9, 2013 at 4:47 PM, Matthias Wessendorf < matzew(a)apache.org (mailto:matzew@apache.org)> wrote: > > > > > > > > Hi, > > > > > > > > > > > > as you know the unified push server has a 'registration' component (see here (https://gist.github.com/matzew/69d33a18d4fac9fdedd4) for details; see here (https://gist.github.com/matzew/2da6fc349a4aaf629bce) for REST APIs) which does the following: > > > > > > > > app registration and adding multiple variations > > > > registration of an installation, submitted from the device > > > > > > > > > > > > There are different roles (as also discussed in the above links).... The "app registration" functionality can be only achieved by something like an "admin"; > > > > > > > > > > > > The admin can create a logical app construct on the server ( Sport News mobile ), which has different variations: > > > > > > > > free for iOS/Android (no user required, everybody can install the app) > > > > paid (same, for both: iOS/Android): User is required, since they pay for extra, exclusive content > > > > > > > > > > > > Now.... the "logical" app construct on the server get's some ID, when the app has been registered... (similar for each of the variants: iOS/iOS-paid etc...) > > > > > > > > > > > > This part of the registration needs to be protected, very well (e.g. OAuth); just thinking out loud.... But yeah... only users, with the proper rights should be able to register (update/delete) apps here!!! > > > > > > > > Device/Installation registration > > > > > > > > However, the other part of the registration (when an installation, from a device, tries to register itself for wanting to receive messages), may be a little more "weak"... > > > > > > > > > > > > Scenario: > > > > > > > > Someone downloads the free iOS app: > > > > once he launches the app and he agrees on receiving push messages > > > > Now... the app should send the generated token (generated by the actual Push Network), to the registration server... (otherwise it can't receive push messages :-) ). > > > > > > > > > > > > So...... the following information needs to be available.... so that the mobile dev. for the free iOS app can register the token with the server: > > > > > > > > APP ID (+ mobile-variant ID) > > > > > > > > > > > > Yes, the IDs are needed.... in order to tell the "registration server": Hey, this installation for XYZ wants to receive messages..... > > > > > > > > > > > > So, the iOS (client SDK) code could look like: > > > > > > > > - (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken { NSURL *serverURL = [NSURL URLWithString:@" http://pusher.server.com/registry/device/"]; PushClient *pclient = [PushClient appID:@"1234" mobileID:@"456454"]; [pclient registerDeviceToken:deviceToken withServer:serverURL success:^(id responseObject) { NSLog(@"Registration Success: %@", responseObject); } failure:^(NSError *error) { NSLog(@"Registration Error: %@", error); }]; } > > > > > > > > > > > > The code above would be used by some customer/user, when they register their app with their running version, of our Unified Push server..... Not sure.... are we concerned about the keys are compiled into the actual app, that everybody could download from the app store ? > > > > > > > > > > > > Others do similar, requiring some sort of "API KEY" (similar to our appID/MobileID pair) being submitted when registering a specific device/installation. > > > > > > That said, without these IDs/Keys.... you can't register an app... > > > > > > perhaps this app/mobile app thing can be used + a "private key" (e.g. for the admin/developer....) and internally we issue some OAuth req., for the registration? > > > > > > I guess.... we should do/recommend some sort of encryption here.... since these keys are compiled into the app....... > > > > hrm... > > > > > > > > NOTE: the appID/mobileID keys are generated by our server, when an admin/developer creates the logical construct of an app, on the server... > > > > > > > > > > > > > > > > > We really can't issue a login in the above case, since there may be no user..... and even if the paid app, requires a user..... someone can still first buy the app, and after installation decide to register a new user, from the app...... so the above code is still executed BEFORE the user decides to active/register his account... > > > > > > > > > > > > Matthias > > > > > > > > > > > > -- > > > > Matthias Wessendorf > > > > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > > sessions: http://www.slideshare.net/mwessendorf > > > > twitter: http://twitter.com/mwessendorf > > > > > > > > > > > > > > > > > > > > > -- > > > Matthias Wessendorf > > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > sessions: http://www.slideshare.net/mwessendorf > > > twitter: http://twitter.com/mwessendorf > > > > > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org) > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

I'm still thinking about your problem (must try before). Is APP ID (+ mobile-variant ID) really necessary?.

I'm just concerned about the non repudiation, for what do you want we could introduce the concept of zero-knowledge proof for devices ( http://en.wikipedia.org/wiki/Zero-knowledge_proof).

I'm not saying it's easy to achieve,

but let me know if APP ID (+ mobile variant ID) can be replaced.

My suggestion is to move forward as is, until we figure out a better way to do it.

Makes sense?

-- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile On Tuesday, April 9, 2013 at 1:20 PM, Matthias Wessendorf wrote: > > So...... the following information needs to be available.... so that the mobile dev. for the free iOS app can register the token with the server: > > APP ID (+ mobile-variant ID) _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev