User Engagement: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
No edit summary
Line 26: Line 26:
* The application code actually running on the phone is the code that was certified
* The application code actually running on the phone is the code that was certified
* The configuration of the phone meets the assurance level requested. For example if a lock screen feature is enabled.
* The configuration of the phone meets the assurance level requested. For example if a lock screen feature is enabled.
* Report on the level of security of user secrets (e.g. Private keys and other credentials). Hardware versus software protection.


===User Intent===
===User Intent===

Revision as of 00:50, 3 July 2021

Full Title or Meme

This topic takes the concept of User Experience to a deeply interactive with the user over time that is intended to help Kantara plan for the next phase of development.

Context

A proposal is in process to extend the Service Assessment Criteria for NIST SP 800-63 into a Trust Registry API for Mobile Applications that act as the User Agent. The existing proposal addresses the first phase of a user experience in acquiring a User Agent that will honor their intent.

The next phase will be the development os specification to the the current set of specification together into a complete package of all of the user attributes, and only those attributes that are required to establish and retain a relationship between one user and one relying party.

What this is NOT about

  • User Engagement is also a term used by marketers to mean user manipulations. This is a technical discussion about the interaction of users with their technology choices.
  • Patient Empowerment is about asserting what a healthcare patient CAN do. This is a discussion about what a user SHOULD do.

Proofs

Identity Proofing

Is the process of binding and identifier to a real-world person. At its core this is just a comparison of biometric factors of the real-world person to user credentials that are accumulated over a user's life-time.

User Authentication

This is the traditional role for an Identifier provider (IdP). In some ways it becomes an anachronism as we disassemble, enhance and reassemple the parts into a complete User Engagement.

User Informed

  • The Relying Party has give the user the information needed to decide to proceed with engagement.
  • The Relying Party lets the user know of any changes before they occur if possible.
  • Where breach or other unforeseen problems evolve the Relying Party will promptly notify the users and possibly the authorities.

User Agent Integrity

  • The application code actually running on the phone is the code that was certified
  • The configuration of the phone meets the assurance level requested. For example if a lock screen feature is enabled.
  • Report on the level of security of user secrets (e.g. Private keys and other credentials). Hardware versus software protection.

User Intent

Consent to share data to achieve objectives.

Proof of Presence

  • Typically this will be real-time identity proofing against biometrics attributes performed in the user agent application software.

Proof of Possession

  • This merely affirms that the user has access to the private key that can create a signature (or similar crypto.)

Liveness

  • The user reamains engaged in the session and is not replaced by someone else.

Currency

  • Proof that user attributes (claims) are still valid.

Problems

  • The biggest challenge is to adequately address the preservation of User Rights in digital interchanges.
  • If the user expectations are not met because of the actions of some bad actors, the users will reveal against the technology and demand better treatment.

Problem Remediation

  • The User Rights will include the ability to cancel or seek redress for descrepancies.

Fraud Detection

Let us not forget that the attack is one user of the system. They can imitate either party in the transaction to divert assets to their own use. It is to be expected that the RP will use techniques to detect fraud and that is beneficial to the health of the ecosystem. The user needs to understand what these are, in broad terms, and consent to the functioning.

Sovereign Surveillance

Governments have a duty to protect both parties to an internet transaction. But they can destroy trust by those actions and must be held to account. For example, if a state insists on the user of their app in the smart phone to enable the mobile driver's license, and then uses that for surveillance, the users may lose trust in the system an fall back to using paper cards rather they electronic replacements.

User Agent Trust

  • The application that is interactive with the RP on the user's behalf is know to protect the user's secrets and intent.

Soltuions

Kantara already has a deep reservoir of experience in the development os specification on the User Experience that can serve as a basis for the next steps.

  1. User Managed Access
  2. Consent Receipt
  3. Mobile Authentication Assurance Statement.
  4. Privacy and Identity in Mobile Driver's License

The path forward

If the existing projects are considered as phase one, which is still in active development, the following items could be consider as phase two.

The objective is to ensure that User Engagement works to the benefit of both the user and the RP. Each party must feel that their needs are adequately met and that one side is not taking advantage of the other.

  1. The consent receipt is being expanded into
    1. a consent record.
    2. a generalized notification.
  2. The MAAS is being bound, in-real-time, into:
    1. proof that the user is present at the device
    2. proof that the software running on the device is same code that received the MAAS

References