Current Topic: 10.1.5. JavaCard-based access matrix
You have a privilege to create a quiz (QnA) related to this subject and obtain creativity score...
JavaCard-based access matrix of membership roles and privileges
The strategy for developing JavaCard-based applications is to keep the absolute minimum amount of data on the card, perform the absolute minimum amount of operations on these data, and outsource heavy tasks to terminal applications.
For example, a terminal application that provides access to distributed knowledge and services unpacks group membership data to check privilege-based access.
When a user requests a service or data via the terminal application, the terminal application grants a specific access type using the access matrix rules provided in the distributed knowledge system.
The illustration below shows an example of the access matrix based on user roles and data and service internal domain types.
Was it clear so far?
Every group can create internal member roles and assign data and services to specific domain types that fit its group agenda. For example, a group of consultants may have roles such as “Developer,” “Release Manager,” and “Editor,” and domain types such as “Source,” “Documentation,” “Personal,” “Plan,” “Status,” and “Management.”
Naturally, a nonprofit group such as “Children under 10” can have different roles and domain types.
Upon a user service request, the terminal application retrieves membership data from the JavaCard, unpacks these data, and applies role IDs to the matrix of access rules. The terminal application grants the proper access type – for example, “read” or “read and create.”
If the requested service is related to a knowledge or service contribution, the terminal application adds some value to the virtual score of the contributor, associates the new data or service with the contributor’s identity key, and may prompt the contributor to indicate specific or default access rules.
If the requested service is related to knowledge or service consumption, the terminal application checks to see if the user’s virtual currency amount is adequate and subtracts some score. At the same time, the terminal application may increase the value of the requested data or service upon its usage.
The next user may find it more valuable or “expensive.” The system may also prepare the addScore operation for the contributor of the data or service that was just consumed. The next time the contributor enters the system with her or his JavaCard, the terminal application increases her or his virtual score.
