Error importing a token by CT-KIP method

[OrlandoES]

I am working on the distribution of software tokens by the CTKIP method through the AM 8.4 Java API. The profile I am using to distribute a token is the generic AES 128, when we try to import it on an Android device it marks the following error "The device class ID" a01c4380-fc01-4df0-b113-7fb98ec74694 "does not match the type of device while processing the CT-KIP client request for the "X" token.

Does anyone know why this happens? Previously it worked correctly.

Error:

[PiersB]

I would verify the profile you're using and whether the profile corresponds with the device on which the software token will run. The Generic AES does not contain a default for the device serial number (aka the "Device Binding ID"). If you take a look at your software token, there is an interface to display the binding ID. When a token is distributed, this binding ID had one of two values:

1. A generic "Binding ID" corresponding with a "class" or "type" of token.  If you look at the other token files (apart from 'generic') you'll see the default binding IDs. Generic has no value for this attribute.
2. A device-specific "Binding ID". For example, this is shown in the "about" screen of the software token:

     (As you can see, it has a link to allow the end-user to email the binding ID to the administrator.)

The administrator can use the Binding ID, at their discretion, to authorize a specific software token for seeding via CT-KIP. 

I would try providing the "Device Class ID" shown as the "Device Serial Number" attribute during token distribution.

[OrlandoES]

Hi Piers,

Through the AM 8.4 API how can we know what type of device is where the RSA application is installed. That is, when I make the distribution, how do I know what type of device it is in order to assign the correct profile?

Is there any example code?

[StevenSpicer]

For new users or devices, that is an administrative problem -- you've got to get that information from the end user, unless everyone is issued company phones with known types.  If you're assigning a replacement token, you can get the profile for the existing token via SDK.  Sorry, I'm not a programmer, so I don't have example code, but I know it's in there.

Using the Self Service Console (or SecurID Access Prime's Self Service Portal) gets around that problem by letting the end user select their device type from a list of available types.

[PiersB]

The idea is that only a super-admin can create "Profiles". The Profiles define the types of tokens you want to support, how they should operate, and how they should be distributed. We expect the customer to define what they want to support. This also clearly depends on the capabilities of the software token. This is why there is a drop-down with various token types when creating a Profile. You indicated that you selected "Generic AES", so none of the normal software token configuration data (i.e. The Binding ID for the type) were used. There are software token definitions for each of the software token releases (Version, platform, etc.) and new ones can be provided and imported into the server. Each Profile, in turn, is then associated with a specific software token definition.

[OrlandoES]

Thank you, I have successfully resolved the issue.

[OrlandoES]

Thank you, I have successfully resolved the issue.

[EricaChalfin]

Orlando ES‌,

Can you share your fix?  It may help others facing the same issue.

Regards,

Erica