A.Admin: different concept for mobile

[BrJu]

From @woodbe The concept of an admin on a mobile device is generally (though not always) different from a more "comprehensive" system. There aren't admin users, but admin processes (such as MDM agents). These admins don't authenticate to the local device and aren't users in the traditional sense. + In general in a mobile device the user is the administrator of the device. It is difficult to say (with a straight face) that an end user is "well trained"

[yamadaAIST]

To mobile devices, the admin is the user themselves, as Brian wrote. There will be no or few management functions that have interfaces to the admin. In such cases, the admin can be said that they are well-trained.

[n-kai]

We would like to propose to replace A.Admin with the following assumption in mobile cPP

A.User It is assumed that the user configures the device correctly in a manner to ensure that the TOE security policies will be enforced.

Rationale There should be no assumption for an admin for mobile however user should at least configure and use the TOE correctly.

A.User is more understandable for readers (MDMPP defines the term "Administrator" so readers who are familar with this PP may be confused if we use different definition for "Administrator")

[nils-tekampe]

But wouldn't that contradict the explanation from @woodbe ? If the user is not trained enough to take the admin role (I can somehow follow this argument), how can they be assumed to configure the device properly?

[n-kai]

I think that mobile user need not be well-trained but need to read the manual carefully and follow them to enrol/verify his/herself or configure the device.

For general biometric system, administror may be well-trained to enrol users correctly.

[woodbe]

I could go with the A.User approach for this. I don't expect a user to necessarily be trained well enough to be an admin, but the processes on mobile devices for enrolling biometrics are designed for someone who wouldn't have been trained in advance. The last manual I saw for a device didn't have anything about fingerprint or iris in it. There are prompts during setup to add such things, but it is expected the user can find where the settings are, but once there, the software will prompt the user to a proper enrollment process. So I can be acceptable of a "trained" user by expecting the documentation or the software surrounding the enrollment process provides the proper training or explanation of what is being done.

[yamadaAIST]

I don't agree to A.User approach. This will lead to make multiple separate individual cPPs in biometrics. That was not the approach this iTc took. In mobile, there will be less administrative functions. If the user (= the administrator) can use these functions, then he/she is well-trained. The SPD should not be changed in principle. I think, but am not sure yet, that the SPD can be applicable to the mobile case by adding application notes if needed. If "Administrator" is thought to be confusing, it will resolved by adding an adjective before "Administrator" such as "Biometric System Administrator". It can be abbreviated as "BS Administrator". Then it is not confusing.

[n-kai]

I also don't want to create mulipule cPP but Nils proposed to create a new tag for mobile so we can be more flexible. I am not familiar with github but the following is my understanding.

We can share description in the current SPD/Obj as much as possibe but we can modify something with the new tag if we have to make use case dependent change and number of such changes are not so many.

[BrJu]

cf. also #38

[BrJu]

Solve with #38 resolution (or will be handled in #38 for use cases 2+)