IDESG Wiki - User contributions [en]

Being Digital

2023-11-27T04:35:42Z

Tomjones: Created page with " Site logo image .Nat Zone Digital Being Nat Nov 3 The COVID-19 pandemic forced many of us to migrate to the cyber-continent at unprecedented speed. It was so sudden that we were not well prepared for it. Up until then, a lot of social constructs were implicitly based on the limitations of our physical existence. It was not possible to instantly appear in a meeting room from a distance in the physical world. You can, in the cyber world, but we lack adequate protectio..."

Site logo image .Nat Zone
Digital Being

Nat

Nov 3

The COVID-19 pandemic forced many of us to migrate to the cyber-continent at unprecedented speed. It was so sudden that we were not well prepared for it. Up until then, a lot of social constructs were implicitly based on the limitations of our physical existence. It was not possible to instantly appear in a meeting room from a distance in the physical world. You can, in the cyber world, but we lack adequate protection and capability to achieve what we can do in the real world.

One of the concepts that I believe useful to contemplate around these issues is “Digital Being”.

Digital Being is our representation in the Cyber-space. We, as physical beings, cannot get into the wires and act directly. Instead, we have to establish a digital version of ourselves and act according to our direction. Any communication is done through this digital being in cyberspace.

To Live in cyberspace, we need to establish our Digital Beings.

It is clear then that we have to be warranted to be able to create and control Digital Beings. I would say:

Right to have Digital Being.

It is a mirror concept to Right to Life in the real world. If you cannot have a Digital Being, you cannot live in the digital world. So, anyone should be able to establish and re-establish one’s trusted digital being. For the communication to be trusted and secure, each entity needs to be able to identify each other with the “digital name” and open secure communication channels between them. That means

Digital beings for a person need to be linked and controlled by the physical person.
Digital Beings must be capable of being authenticated by the party it is communicating with.
They need to be able to send and receive signed messages among themselves.
If a dispute occurs, the person controlling the digital being must be accountable for it.
When one’s digital being fails (e.g., for technical or operational reasons), he should be able to re-establish it.
Mind you. This is not warranted yet. Many people still do not have access to the internet, and as a result, they do not or cannot have Digital Being. So, this aspect needs to be addressed, but I am not doing it today. Instead, I am focusing on the desirable properties of Digital Being. It is still a work in progress, but I have summarized it in the following seven principles:

Accountable Digital Being
Expressive Digital Being
Fair Data Handling
Right NOT to be forgotten
Human Friendly
Adoption-Friendly
Everyone benefits
Let me go over one by one.

Accountable Digital Being
I don't think you go out into the city centre and suddenly start shouting random things or slandering people. This is because you will be made to explain why you did what you did, and you will be held responsible for the consequences of your actions.

In other words, we are "accountable" in the real world, and we don't do stupid things in public. Of course, some people do, but they are so rare that they are featured on news programmes.

In contrast, what about the current state in cyberspace? Do not people think they are hiding in a safe place, that they will not be identified, slandering people and shouting conspiracy theories aloud? Of course, if you probably are not. But it is a fact that many people do. We have seen many cases, and one of the symbolic cases is the death of a 23-year-old reality TV actress who was stormed by a mob on social media accusing her of acting in that TV programme. She was psychologically cornered and chose to end her life.

Such a mechanism would allow a person who has committed an unlawful act that is injurious to others to have his or her anonymity lifted and to be able to

(1) give an account of what they have done

(2) provide evidence that the act was justified

(3) be punished if it is shown from (2) that the act was not justified.

In other words, accountability is required. The more people are made aware of this, the more they will consider whether or not the actions they are about to take part in - such as flaming - are really socially acceptable. People who are involved in flaming incidents are often doing so out of "their own justice". In other words, they are carrying out a "private justice" and deriving pleasure from it. However, when users tried to send an offensive message and the ReThink app asked them if they were sure they wanted to, 93% of the teenagers involved were discouraged from doing so.

On the other hand, in a context where this kind of responsible digital existence is becoming more and more common, not having it can lead to social exclusion. Therefore, we need to be able to establish it whenever we want and to re-establish it if we leave it for any reason.

Some aspects of this requirement are often discussed in the context of DID. However, you can see that it is not a purely technical construct. It will likely involve the notion of trusted parties identity proofing and registering the person in some form or manner. At the same time, there needs to be a technical measure that helps it. I am looking forward to that cryptographers would be able to assist in this respect.

2. Expressive Digital Being
This principle says that a Digital Being should make it possible to communicate what kind of person you are to others by using attested claims about your characteristics. ===

Harvard Study of Adult Development is known to be the longest-running study exploring the source of happiness. It has been following up panel since 1938. The first batch in the study was 268 second-year students in the Harvard, and 19 was still alive in 2017. The second group was chosen from the youngsters in extreme poverty. Most of them lived in apartments without running water.

At the outset of the study, these teenagers were interviewed, went through a health check, their parents were also interviewed. They became adults and pursued various lives. There were factory workers, lawyers, doctors and so on. One of them became the 35th president of the United States: John F. Kennedy.

Eventually, 1300 additional children were included in the study. In the 1970s, 456 inhabitants in the central Boston area was added, too.

They continued to fill the questionnaire every two years and received interviews. What was made clear from the 10s of thousands of pages of information was this: ✓

Good relationships keep us happier and healthier.

It was not fame or wealth. It was the relationships, especially with those you are close with.

Then the question becomes: How do we build relationships?

It is by expressing ourselves to the people we want to have good relationships with.

This figure shows you on the left as the entity trying to build good relationships with various people. The upper side is with her friends, and the bottom side is with her boss. There are many more contexts like these, but I did not feel particularly useful as you can extend the argument to any number of context, so here are just two.

You have your self-image that you want others to perceive you as. Sometimes, it is called “identity”.

Now this self-image is an abstract object that your friends or boss cannot perceive directly. In real life, you project it onto them by providing the information on how you dress, what scent you wear, how you speak, where you live, your partner choice, and so on - that is, you expose various attributes about yourself and the recipient will indirectly obtain your self-image.

Now, this projection is not always successful. You cannot control how these attributes, or identity, is being perceived by the receiving end. So, there always is a difference between the self-image, or “identity”, that you want them to perceive and what they perceive. You try to minimise the gap by continuously providing the receiver with other attributes. When this does not go well, and the gap remains large, it results in interpersonal problems and causes unhappiness.

Now, let’s take a moment to look at the data leakage case. For example, suppose that an attribute that was only provided in the professional context leaked and was made available to the friendship context above. Since the gap was minimized to start with, this will likely enlarge the gap. This is what we know of as “Privacy Invasion”. It makes this person less happy.

It should be clear by now how important it is to be able to project attributes selectively to receivers depending on the relationship context. I am calling this ability “Expressiveness”, and the second principle of “Expressive Digital Being” is about this property. Without it, we will not be able to optimize the relationship.

It has several implications.

One needs to be linked to and control their Digital Being.
One need to be able to authenticate the party they are communicating with, and vice versa.
One needs to be able to provide fine-grained selective disclosure of the attributes.
OpenID Connect that I helped create is a technology that enables something like this. It is a selective disclosure mechanism, albeit it is almost entirely dynamic. There are two kinds of model:

Aggregated Claims Model
Distributed Claims Model
In both modes, there are multiple Attribute Providers, which in OpenID Connect is called Claims Providers. This is because authoritative sources of these attributes/claims are decentralized. For example, while the City Office is authoritative on your registered address, your employer is authoritative on your employment record, and your university is authoritative on the degree that you have obtained. They will never be made into one. There always are going to be many of them. Thus, there are many attributes providers.

Identity Provider is the party that controls the overall flow. In some jurisdictions, it is called “Consent Manager” as it obtains consent from the person/user to provide the attributes to the client or receiver. I do not particularly like the name as the role of the individual is passive, by the way. I would like a more active role by the user that user orders or instructs the Identity provider to project the attributes for them. Thus, I like the term Identity Provider better than Consent Manager.

Anyways, … getting back to track …

In this model, the identity provider, C, dynamically gathers the claims that the user wants to provide to the client, D, as signed claims. Then, assemble them with the claims that it is authoritative, for example, the user authentication result, and signs them and provides it to D. To make this possible, the user has to go through the setup phase where they grant A and B to provide the claims about them to C. A and B have to authenticate U at the point. As the result of the grant, C obtains access tokens Ta and Tb respectively for A and B. When D asks for claims a and b, C first asks U if it can be and after obtaining the permission, goes to A using Ta to obtain signed claim set a, then repeats the same thing to B. Note that user identifier of U at A and B are likely different. To prove that a and b are about the same subject, U, it either has to contain a common user identifier or nonce. Both A and B may be able to attest many claims, but for collection minimization, it should only attest the minimal claim set. In OpenID Connect, since everything is dynamic, that is, a and b are minted at the time of the request by D, this is easy. The gathered signed claims with the same nonce will be aggregated into this response and provided to D so that D can verify the signature on a, b, and c.

Note I said that everything is dynamic in OpenID Connect. We opted to take care of the 80% of use case that way. There are use cases that are not fulfilled by this approach, namely when A and B can become offline and the claims cannot be obtained dynamically. For example,

when you want to provide attested claims from a party that is no longer exists
When A is only willing to provide static document encoding the attributes
Under these circumstances, U need to store the signed claims set that exceeds what D may want. Now, the question becomes more complex than before. You need to be extract only the claim D wants and still be able to prove that the claim was not tampered with. If I understand correctly, the mobile drivers license per ISO/IEC 18013-5 tries to deal with this problem. It takes the salted hash of each attribute values and essentially concatenates them and signes over them. When providing only one claim, it C can provide the value of that claim together with the hashes of other claims and signature over them so that D can verify that the attribute value matches the corresponding hash and the entire document is not tampered with. This is neat, but is losing one privacy characteristics if I am not mistaken. These hash values acts as omni-directional identifiers: the receivers can correlate the arrival of the user at different instances or different receivers if they collude. If you could come up with some cryptographic magic to mitigate this correlation problem or solution to selective disclosure form a static document stored at C, the entire identity community will rejoice, in my humble opinion.

Distributed claims model works similarly but now the claims are not provided through C but D obtains them directly from A and B. This works better in the case where D needs to be continually updated on claims a and b and when C can be largely offline. Unlinkability of D from A and B is lost in this case.

3. Fair Data Handling
In this way, individuals seeking their own well-being will actively and selectively give out their data. However, in order to do this with confidence, they need to be able to trust that the data they give out will be treated fairly. You don't want the information that you gave to a friend saying it is only between us to be shared with all the other friends. Similarly, if you give out information only to one company and it gets leaked to the public, that's not good. The discrepancy between your self-image and that of other persons, which has been minimised so far, will widen.

The unauthorised publication or disclosure is just one example of improper handling. There are many more examples of inappropriate processings. Any handling that is outside the scope of what the individual concerned expects, or that could cause harm to the individual, is inappropriate handling.

In recent years, this aspect has often been discussed in the context of Centralized v.s. Decentralised Identity, but from my point of view, it is missing the point. What is important is whether the data handler is a data controller or data processor. When folks talk about Centralized, they kind of imagine Big Techs. They are data controllers. Thus, they use the data as they need. And they contrast with the smartphone wallet based implementation as decentralized. In this case, the wallet is a data processor so it processes the data only according to your instructions.

However, when you think twice, the topology actually does not matter. If the wallet provider is a data controller, your control is actually gone, while if the Centralized IdP is acting as a data processor under your control, a large part of the problem is actually gone.

From this, we can see that the issue is about who retains the control, how transparent the processing is, and whether an appropriate practice is followed by the processor.

In order to be considered appropriate, the privacy principles must be adhered to, for example, in accordance with a privacy framework such as ISO/IEC 29100.

　To ensure that the processing does not go beyond the expectations of the individual concerned, they need to communicate to the individuals exactly what they intend to do. This is where the Privacy Notice comes in. The standard for this is ISO/IEC 29184, of which I was a project leader.

　For individual systems, it is also necessary to develop a system for risk assessment and stakeholder approval using the Privacy Impact Analysis (PIA) framework. The PIA will involve external stakeholders and the publication of a PIA report, which will provide a degree of transparency and monitoring of the operation to third parties.

　In order for this kind of legitimate handling of data to become more widespread, there will need to be not only legislative pressure but also social pressure. In this sense, the onus is on each and every one of us as members of society.

4. Right NOT to be forgotten
This may sound strange as “Right to be forgotten” has been heard so many times, but this is not a mistake. This in fact is a flip side of the Right to be forgotten, and I believe that it forms a basic Digital Being right in cyberspace.

Let me pose this question.

When does a person really die?

Of course, when the heart stops beating, that is one death, but this question is not talking about that. The classic answer is

When the person is forgotten by everybody.

The corollary of this for the people who migrated to the cyber continent is “When all of their data is deleted.”

Naturally, it should be allowed to disappear if one so desires, but otherwise, it should be possible to have the record of Accountable Digital Being to remain.

In addition to physical extermination, social extermination also works as a potent way to exterminate a person in the cyber continent. This is done by rewriting a person's attributes to make them socially undesirable in the eyes of the mainstream of the day. In modern Japan, this can be done by labelling a person as a paedophile or a misogynist and then spreading the word as such. Even if you don't go that far, simply deleting your university graduation record and declaring you a fraud would be damaging enough.

A digital being needs to be able to counter these attacks. It needs to be able to store attributes about itself that are signed by the issuer of those attributes. The issuer may later claim that the key used for the signature was not there, so this must also be recorded in an objectively unfalsifiable form.

In view of this, it is important to store the signer's key in a time-stamped and widely stored repository, such as the blockchains used in various economic activities, so that anyone can later verify that the signature key was valid at the time, or, if the need arises It should be an option to write your attributes in such a place so that an attacker cannot delete or change them. This way, even if the physical entity in the real world is deleted, it will remain as a memory in the cyber continent.

Now, how do we achieve it?

It is often claimed that Decentralised Identifier, DID, and Verified Claims with Wallets on smartphones as IdP would solve this problem. Recently announced European Digital Identity Regulation proposal also talks about “Wallets” so it may be thinking similarly. However, I am actually dubious of such claims.

True, if the IdP is run by yourself, it will not ban you. But if the IdP is implemented as an App, then the platform provider can ban that app. That will remove your access to the identity holder and that's almost the same as account banning. We had a prominent example in the game sphere a few years ago.

(source) Fortnite: Nineteen Eighty-Fortnite https://www.youtube.com/watch?v=euiSHuaw6Q4

If that was in the identity wallet sphere -- just imagine it. They can just find the app saying that it does not support the platform identifier that it violates the developer agreement. It's exactly the same situation.

Also, unless you code your App yourself, you would not know whether that App is trustworthy. It may be collecting your data in disguise. Such examples abound.

Even if the App provider is not malicious, it may still be dangerous. Suppose that the app provider was using a hacked compiler that includes the malicious code in the resulting binary. The malicious code may extract the claims you store in the App and start selling. It will not be detected by Apple review as there is nothing in the source code that exhibits malicious behaviour. Recently, many apps were removed from the App store exactly because of this reason.

From the point of view of the data receiver, you do not know if the App you are interacting with is legitimate or not. There currently is no standardized way of recognizing the binary identity of the App from the remote, as far as I understand. As there are some proprietary libraries that try to achieve it, what is likely is that each data receivers start providing Wallets. If you look at QR code payment area, this seems to be the case.

This is indicating that requirement 5 is likely not able to be solved by purely technical construct. We probably need legal and business construct as well. The new European Digital Identity regulation proposal seems to be aware of it and is requiring Wallets to be certified.

Also, we could leverage competition laws and telecommunications laws to prevent the ban by the platforms.

But this tactic works only in the case where we have a democratic government. It does not work under an oppressive regime. Let's consider the case where you became an enemy of the State by becoming a freedom fighter.

What the state is likely to do in the case is ban the identity, wipe the identity, or rewrite the characteristics to smear you.

Actually, even a democratic government may sometimes try to do it. In a democratic government, a higher governance scheme such as constitutional rights may help alleviate such risk in the end. However, under an oppressive scheme, it will not.

Here, technological measures can help. For example, if the keys are time-stamped and if you write those signed claims or credentials into immutable ledgers that are used to buy other economic activities as well, it will become extremely difficult for the government to wipe it or rewrite it.

I hear the cry saying, “Thou shall never write personal data onto blockchain because of privacy! You will not be able to delete the data. Right to be forgotten is violated”.

Well, is it so?

Surely, in normal cases, and under most circumstances, it shall not be.

However, this is an exceptional case. It is an existential case. You are about to be deleted from this world. If writing data about you into the ledger so that it cannot be deleted will protect you from being deleted from the physical world and from people’s memory, what would you do?

Remember my earlier question: When does a person die? When the heart stopped beating? That certainly is a physical death but we do not live only in a physical form. We also live as a memory. Your real death comes when you are deleted from people’s memory or re-painted in the memory of your close friend as a dirty, filthy, liar.

You need to write your personal data into the immutable ledger to achieve your right not to be forgotten.

Right NOT to be forgotten.

Then, while your physical being may be deleted, your digital being remains. It will put societal pressure onto those powers then.

5. Human Friendly
When we think about information systems, the people who use them should be the first thing we consider. In practice, however, the convenience of the people and machines who manage the system often takes precedence. The result is a system that is "difficult to use" or that "tricks" people.

　In thinking about being human-friendly, there are a number of considerations that need to be made about the individual. The main aspects that I usually put forward are:

(1) the asymmetry of information between individuals and legal entities;

(2) The bounded rationality of individuals; and

(3) The existence of socially vulnerable people who are not part of the majority.

The asymmetry of information between individuals and companies means that companies generally have more resources and information available to them than individuals. In an information economy, the one with more information has a trading advantage. As a result, in a purely market economy, the optimal equilibrium is not reached. Therefore, measures are needed to support the individual and reduce the information asymmetry. Third-party evaluations and their publication or a counsellor working for individuals are one such initiative.

The second point, the bounded rationality of the individual, refers to the fact that, due to the limits of our cognitive abilities, we are limited in our rationality, no matter how rationally we try to act. For example, if a rational individual wanted to enter into a contractual relationship with an entity, he or she would have to read and understand the contract, understand the laws and circumstances surrounding it, and then act accordingly. But most people don't. In fact, it's impossible. Most people would not be able to read and understand the wording of a contract, and even if they had the ability, it would take them a month to read all the privacy policies presented in a year. The operation of society on the cyber continent should be based on an acknowledgement of this.

　For example, if you are providing a service to an individual, your terms of use and privacy notice should be as similar as possible to what one would expect from common sense, and only the differences and important points should be extracted and presented to the individual, with the full text available for later reference. This is also in line with the GDPR as far as I understand.

Some people claim that if the IdP was operated by the individual, then it will not misuse the data. But by now, you are aware that is not the case. We do not know if the App is well-behaving. It could be even easier if we put forward a legal framework to control the “centralized IdP”. What is important here is that the individual become the data controller in principle, and the providers of IdP service become data processors. The topology of the deployment really is not the decisive factor.

It should also be noted that for many people, actively managing one’s IdP is just too much or too dangerous.

　The third point is that the existence of marginalised groups means that such non-mainstream people should not be left behind, and that the system should be such that they are not left behind.

　Those who stand on the side of the majority tend to mistakenly believe that their common sense is just, or that what they are comfortable with is sufficient. In many cases, however, this leads to brutality against minorities.

　Some minorities are minorities in terms of physical characteristics and abilities, others in terms of ideological beliefs and cultural backgrounds. The needs of these people are easily ignored by the majority, out of indifference and sometimes out of a sense of 'justice'. The new rules of the cyber continent must not allow this to happen. And if we are kind to the minorities, we will surely be kind to the majority, both in terms of perception and user experience.

6. Adoption-Friendly
　When a new technology comes along, it is rarely zero-based and completely new, and it rarely replaces the existing one in one single swoop. Usually, they are built on top of the existing infrastructure. In this context, it is important for new technologies to consider their compatibility and connectivity with existing technologies.

Many engineers like a clean slate. They want to entirely replace the systems. That’s a hard sell. Most technological advancement happens incrementally.

Let’s think about the railroads. When electric trains were introduced in the system, they replaced diesel engines with motor-based engines, but they did not replace the rails or stations. It continued to use the existing rail systems.

When automobiles were introduced, they replaced the horses with petrol engines, but it did not need a totally new set of roads. The roads were improved gradually. If they needed new roads to be built, the market penetration would have been much slower.

　Also, open technologies are far more likely to spread than closed technologies. This is because an open development process is more likely to attract requests from a wider range of stakeholders, resulting in a wider range of applications, and is more easily disseminated to engineers.

In addition, to ensure interoperability, a common testing platform is needed to ensure compliance with specifications. This can be seen in the case of Open Banking in the UK. Standards are written in everyday languages such as English. However, everyday languages, unlike programming languages, are open to a certain degree of interpretation. As a result, it is not uncommon to produce different implementations that do not connect each other from a standard. In the case of Open Banking in the UK, it often took weeks for a bank to connect with a Fintech in the beginning. The solution was a suite of compliance tests, through which the time taken to connect was reportedly reduced to around 15 minutes.

It's not just about initial connectivity. Systems are subject to change for a variety of reasons. At these times it is also necessary to check that compatibility is not compromised. If a conformance test suite is in place and used for ongoing development, the risk of incompatibility can be significantly reduced.

7. Everyone benefits
　The last principle, "everyone benefits", is not often mentioned, but it is a very important one. Environmental change that comes at the expense of a few is difficult to implement, and even when it is implemented, it does not last.

　When privacy is a priority, it can be easy to focus on strengthening individual rights, and when efficiency is a priority from a business perspective, individual rights can be seen as a distraction. However, any attempt to strike an imbalance is likely to be met with fierce opposition, resulting in a situation where the status quo is maintained or even worsened. It is also unethical to allow the tyranny of the majority to overwhelm the minority and allow the majority to profit.

There is a concept in economics called Pareto improvement. It's a change where no one is worse off and someone is better off. Fortunately, the use of data is not a zero-sum game. Data is not consumed or lost when it is used, and if used with care, both the companies that use it and the individuals who allow it to be used can benefit. In many cases, Pareto improvements are possible.

　Although the figures are a little out of date, a 2016 European Commission report suggests that the increased use of data will account for 5.4% of GDP in the EU27 by 2025.

　In order to receive the fruits of this system, individuals, companies and governments must shape it in such a way that they can benefit from it. Otherwise, the system will not be implemented and will not be able to stand as a system.

So, these are the seven principles of Digital Beings.

They are not purely technical, but do involve social, legal and business constructs.

However, there probably is a lot that cryptography can provide.

I am hoping to collaborate with you in the coming days.

Comment
Manage your email settings or unsubscribe.

Trouble clicking? Copy and paste this URL into your browser:
https://nat.sakimura.org/2023/11/03/digital-being/

Trustmark Evolving Design Pattern

2021-12-16T16:05:04Z

Tomjones: /* User and Web Site Acceptance */

= Design Pattern Metadata =
Draft: February 2016

==Title==
[[Trustmark Evolving Pattern]] shows how the [[Trustmark]] can be included in web pages without breaking existing user patterns of behavior. It’s most effective when it evolves as users gain an understanding of the benefits that are offered by Identity Ecosystem Framework (IDEF) compliant web services providers.

==Status==
===Design Pattern Lifecycle Status===
{| border="1" padding="2" width="600px"
|Contributed || Working Draft || bgcolor="SteelBlue"|'''Committee Review''' || Compilation || Approval || Publication
|-
|colspan=6|This Design Pattern is available for review by the User Experience Committee (UXC) with the goal of refining and completing the Design Pattern, see [[Identity Design Patterns]] for the current list of design patterns and their status.
|}

===Design Pattern Review Status===
This draft is current as of February 2016. In UXC committee review and out for other committee informal review.

Expect changes before this pattern is final.

==Contributor==
Tom Jones <br>
Mary Hodder <br>
Edits: <br>
Ellen Nadeau <br>
Mary Hodder

= Design Pattern Content =
==Problem Description (meme)==
[https://wiki.idesg.org/wiki/index.php?title=Trustmark_Evolving_Design_Pattern#Actors Users] need to be able to make a trust decision from the information on a publicly accessible internet site with an IDESG Trustmark. The user may not have a fully formed trust opinion when first navigating to the site.

The IDESG concepts need to be incorporated into an existing online displays to users without major disruption and then evolve in the following ways:
# Existing successful web sites may be reluctant to risk major changes that alienate users and the prominence of IDESG Trustmarks will grow as the user's understanding grows.
# The terms of use of each Trustmark will evolve as user and regulatory understanding grows.
# The identity Ecosystem itself will evolve as new Trustmarks are added to accommodate user's growing expectations.

While there may be sites that are not publicly accessible that have an IDESG Trustmark, they are outside the scope of this committee.

==When to use this Pattern (Context)==
* Any time a user is asked to provide identification or personal information to gain access to a web service. This pattern specifically focuses on the interaction with a relying party (RP).
* The IDESG is contributing to the development of the Identity Ecosystem, which consists of multiple trust frameworks that satisfy the needs of specific affinity groups. Since users need to communicate with different affinity groups from time to time, they may need to accommodate different trust frameworks during the normal course of daily computer use. Each affinity group can specify restrictions on the attributes collected from users as well as the way those attributes are handled by the entities that have access to them, as long as these entities adhere to the same trust frameworks.
* Some web sites can determine in advance which Trustmark applies to them by the nature of their business. They will be able to display one or more Trustmarks that will apply to all interactions with the user.
* Web sites may operate with the user under different levels of trust and assurance and so will have different trust contexts during different parts of the interchange. When more than one Trustmark can apply the user may have the ability to select the Trustmark, and hence the context, under which the reset of the interchange will be conducted.
* The Relying Party (RP) can voluntarily determine which Trustmark policies will provide it with the information it needs to allow access to its site.
* The RP will voluntarily choose to support one or more IDESG trust frameworks known to follow IDESG principles for the user to choose from. When the IDESG process is just starting it is expected that most RPs will continue to support other identity providers. Over time it is hoped that the IDESG process will become widely accepted so that many RPs will be able to support only IDESG trust frameworks.
* It is expected that each trust framework will come with a set of rules and approved independent labs that can attest to the web site based on the trust frameworks that are supported by the site.
===Relationships with other Design Patterns===
This design pattern is a specific internet pattern that derives from the pattern described in the [[Design Pattern: Common to any Internet Identity Ecosystem]]. Other specific design patterns that relate to this one are:
*[[User Registration Ceremony]] with an Identity or Attribute Provider using one or more IDESG Trustmarks.
*[[User Intent Pattern]] is used to acquire the user's intent to allow linking to be passed to the Relying Party.
*[[User Choice Pattern]] is used to allow the user to select which attributes are released to a relying party.

===Relationships with Use Cases===
The [[Trust Elevation Use Case]] describes the case where one interaction between a user and a relying party could result in the application of different Trustmarks during a single web browser connection. This is one possible scenario for retail sites where users are not asked to identify themselves until they are committed to the buying process.

===Actors===

The following roles are the ones most likely to be involved in the deployment of Trustmarks. Note that some of the roles may be collocated in a single site on the Internet. This section uses the "Entity" definition of the IDESG Functional Requirements as any organization providing or using identity services. Before all of this can be defined there needs to be an Identity Ecosystem that defines the use of Trustmarks. The Identity Ecosystem is designed to securely support transactions that range from anonymous to fully-authenticated and from low- to high-value.

# '''User:''' An individual human being This does not include machines, algorithms, or other non-human agents or actors.
# '''User Agent:''' in this case any piece of code that displays a user experience and obtains responses from the user in order to satisfy the privacy concerns of the user and the need for identity and attribute claims by the relying party.
# '''Entities''' The collection of all internet based services with which a user will interact to create, supply and consume identity and attribute claims as required to complete the task that they have undertaken.
##'''Identity or Attribute Provider (IAP):''' An entity that contains identities and of users that will be provided on demand in claims that the user can forward to a RP.
##'''Relying Party (RP):''' An entity that needs a collection of claims to provide that service; the RP might rely on a collection of claims from different identity or attribute providers.

==Solution==
===Description of the Solution===
# The user establishes an account with one or more IAPs that are accredited with one or more IDESG Trustmarks. In this case there is no need to distinguish between identity providers and other attribute providers.
# The user accesses a web site which at some point requires identity and attributes claims of some sort to continue to process the user request. That web site then transitions from a purely anonymous information site into a relying party.
# The RP gives the user a choice of which IDESG framework (with its Trustmark) or legacy provider provides identity.
## In general the identity provider will be a distinct role from the RP where a persistent identity across multiple interactions is desireable.
##The option of ephemeral connection ID may be provided at the RP's options where anonymous interactions are permitted.
# This request for information is intercepted by the user agent, or any privacy-enhancing technology intermediary—complex step where user drop-out is likely.
## Determine if the information is available based on the specific requested attributes from the RP.
## Determine if the user has already authorized release or the required identity or attribute claims to this RP.
## Display any remaining choices to the user to acquire more attributes or release those already available.
## Format the set of requested claims into a response in a way the RP can evaluate the claims.
## Send the response (including the Trustmark) to the RP who has sole responsibility to determine if sufficient identity has been proved to provide the request access.
## Repeat these steps till the RP is satisfied or one side gives up.
# All parties should ensure that the Trustmark is explicitly included in all interchanges with every party that adhered to the Trustmark's conditions.
## All parties that receive a message that includes the Trustmark are bound by the restrictions contained in the Trustmark as well as those published by the IDESG.
# Trustmark UX should consist of:
## An icon in one of three sizes: Large (nxm pixels), Medium (nxm pixels) and Small (nxm pixles)
## A meme that can be displayed on the web page or in a mouse-over of the icon in Large (560 English characters), Medium (280) or Small (140) that may not be altered by the web site except for localization.

The following images show one way (with some options) that an IDESG Trustmark might be combined with framework Trustmarks and existing IdP service marks at an RP.
[[File:TrustmarkUX2.png]]

===Trustmark Anti-Patterns===
This section describes some patterns of user experience that should be avoided when displaying a Trustmark of value for the Ecosystem. The patterns are ordered from specific to the more general. The first items are those solutions that have been tried, but failed, to deliver on a promise of better security for privacy in the past. The latter items are those that violate accepted usability experience principles. All anti-patterns in the common design pattern[https://wiki.idesg.org/wiki/index.php?title=Common_to_any_Internet_Identity_Ecosystem#Anti-patterns] are explicitly included by reference.

Note that this section does not make any judgement about whether such user elements need to be shown for legal reasons. It only offers suggestions related to usability and user experience.

# An icon at the bottom of a page. Past attempts to inform users as to the security or privacy of a site were able to apply to one of the third party labs for permission to use an icon that demonstrated their compliance. Users did not understand what the icon meant and when the icons were relegated to the bottom of a page, often not displaying on user devices unless the user scrolled to the bottom, they became completely useless as a user experience. [[citation needed]]
# Annual statements of compliance. Many of us receive those multi-page privacy statements that have proliferated since the Federal Government started to “enforce” privacy. Maybe the first one was read because of its novelty, but over time, users have become inured to them, and are often used as the basis now for class action suits, which don't help users before, during or after a problem occurs. Users don't read or understand how they apply and therefore these statements fail to help users decide whom to trust. [[citation needed]]
# An unsubstantiated or generic claim. Amorphous and high-level statements of corporate intent are not specific, and often don't mean anything to users, but are common. They have no practical value to the user, and where corporate lawyers have become involved, it sometimes is the case that they have no legal meaning either. [[citation needed]]
# Withholding context. Display of a Trustmark without giving context for which is applies or defining its boundaries could prompt users to infer a Trustmark should be trusted for more than is correct, leading to unrealistic expectations for the value of the mark. [[citation needed]]
# Too much detail. Identity and personal data management policies today suffer in part from an overload of information where a user doesn't have the time or ability to understand the ramifications of these policies when applied. Trustmark language should not suffer from too much information so that it becomes useless. [[citation needed]]

===Context for a Trusted Interchange===
* Trust is expected to survive for the duration of the interchange, from the time that the user clicks on the trust element, till the time that the interchange is complete and all user claims have expired. This means that every party to the interchange receives notification of the applicable Trustmark and implicitly agrees to be bound the by terms of the Trustmark.
* An interchange that has occurred under the terms of one specific Trustmark should continue to be recognized as meeting the restrictions of the IDESG and the specific Trustmark, which should be attached to the interchange in a secure manner.

===Error Conditions===
USABLE-3 states that “Information presented to USERS in digital identity management functions MUST be in plain language that is clear and easy for a general audience or the transaction's identified target audience to understand.” This applies to error messages, which should be expressed in plain language, clearly indicating the problem and constructively suggesting a solution.

Any error condition that requires user action should create the following user experience elements:
# As much detail about the cause of the error that would help the user understand, while not significantly impacting the user flow or security.
# A way for the user to mitigate the error. The response "Please contact your administrator" does not qualify as a mitigation step.

The following are specific errors that the user might see.
# User does not have credentials that can generate claims acceptable to the relying party.
## Mitigation option: The provider redirects the user to one or more sources of appropriate credentials that do meet the criteria for authorization at the RP.
## Mitigation option: The relying party redirects the user to one or more Identity Providers or trust frameworks that are acceptable. If a new framework is chosen, that may involve user acceptance or change the PET to meet those particular authorization requirements.
## Mitigation: The user is allowed to back-out of the current path to one where they can succeed.

Related requirements from IDEF v1:
• PRIVACY-10, user option to decline, indicates that: “users must have the opportunity to decline registration; decline credential provisioning; decline presentation of their credentials; and decline release of their attributes or claims.”
• PRIVACY-BP-C, recommended consequences of declining, states in part: “if information collection or attribute value release is designated as mandatory, that designation should include a short and clear description of the consequences of declining to provide that information or allowing that release.
• PRIVACY-11, optional information, states: “Entities must clearly indicate to users what personal information is mandatory and what information is optional prior to the transaction.”

===Usability Considerations===
Other considerations for this section of this document have been collected in the [[Common_to_any_Internet_Identity_Ecosystem#Usability_Considerations]] since they apply equally well to any design pattern for display devices attached to the internet.

It is expected that when a user first navigates to a service provider that the interaction will be treated as anonymous and no user data will be collected until the user selects some action which explicitly requires user information, such as clicking a logon or framework logo. The user cannot be expected to have made any trust decision just because they have landed on a web location. As an example the user should not expect that whitehouse.com was trustworthy. Note that it is only after the web site renders that the user can see if the URL is trusted (e.g. if it has a trusted EV-certificate.)

All IDESG logoed web sites are expected to participate in setting a trustworthy context. This design pattern will be combined with other design patterns, including IDESG general patterns to help design and build web sites that meet IDESG UX goals. For example each web site needs to allow users to stop, cancel or back out of decisions when they change their mind.

One important part of any Design Pattern is the intelligibility of the design to the user. IDEF v1 requirement USABLE-3, plain language, states: “Information presented to users in digital identity management functions must be in plain language that is clear and easy for a general audience or the transaction’s identified target audience to understand.” This is applicable to trustmarks; users should understand the meaning of the Trustmark sufficiently well to make an informed consent decision.

When displaying trustmarks, providers should also comply with IDEF accessibility requirement USABLE-5: “All digital identity management functions must make reasonable accommodations to be accessible to as many users as is feasible, and must comply with all applicable laws and regulations on accessibility.”

The reader is also encouraged to read the report of the IDESG experience committee on use case usability at [[UXC Use Case Mapping]]

===Evolution of a Trustmark===
Users should be made aware of the status of a Trustmark, especially when it has been revoked. It is important that there be a central location where all of the IDESG certified Trustmark status be available to any inquirer. It is incumbent on the Trustmark itself to publish notification of facts about its evolving status to any organization that subscribes to it and to the individuals and organizations that are members of its programs. In the event that members have reason to believe that a Trustmark is failing to live up to the representations it has made public, or that it has ceased operations, it should bring these concerns to the Trustmark itself and to the mailing list maintained by the Trustmark.
*'''''Proposed''''' with a proposed version number of 1.0.
*'''''Accepted''''' and a version number is assigned with a certificate from the IDESG.
*'''''Revision Proposed''''' with a proposed version number indicating if a major or minor revision.
*'''''End of Life''''' is indicated when a Trustmark is no longer being maintained. This can also be used to indicate that the sponsoring organization has ceased to exist, but the certification is still valid.
*'''''Revocation''''' indicates that a Trustmark has lost its certification.

===Value Proposition===
One of the most difficult acceptance barriers for most new design choices is the web site of the relying party. If any part of the implementation hinders use of the web site, the feature may not be implemented. The Trustmark evolution depends on increasing the value of the web site at every stage of the evolution. For early adoption by web sites that means that users or partners will prefer dealing with a web site that shows the Trustmark and delivers on the promise that is contained in the terms of use for that Trustmark. That implies that some organization has taken the responsibility to validate the web site before and during operation.

===User and Web Site Acceptance===

Back in 2000 the FTC had the following to say.[https://www.ftc.gov/sites/default/files/documents/reports/privacy-online-fair-information-practices-electronic-marketplace-federal-trade-commission-report/privacy2000text.pdf FTC ''PRIVACY ONLINE: FAIR INFORMATION PRACTICES IN THE ELECTRONIC MARKETPLACE A REPORT TO CONGRESS'' May 2000] There is little evidence to-date that things have changed.

The 2000 Survey also examined the extent to which industry's primary self-regulatory
enforcement initiatives online privacy seal programs have been adopted. These programs,
which require companies to implement certain fair information practices and monitor their
compliance, promise an efficient way to implement privacy protection. However, the 2000
Survey revealed that although the number of sites enrolled in these programs has increased over
the past year, the seal programs have yet to establish a significant presence on the Web. The
Survey found that less than one-tenth, or approximately 8%, of sites in the Random Sample,
and 45% of sites in the Most Popular Group, display a privacy seal.

= NSTIC Guiding Principles Considerations =
==Privacy Considerations==
There are three sources of leaks to user private information that are considered by this pattern:
# The user agent provides more information to the RP than the user intended.
# The user interacts with the RP over an extended period allowing the RP to determine the user ID from their behavior.
# The RP has privacy policies that are obscure or not followed. A multipage privacy policy is ipso facto obscure. Often leaks of user private data are allowed by insufficient security at the RP or other parties that have access to the data.
More details of the IDESG v1 privacy concerns can be viewed [https://wiki.idesg.org/wiki/index.php?title=Design_Pattern%3A_Common_to_any_Internet_Identity_Ecosystem#Privacy_Considerations here].

Other privacy considerations, such as an expressed user intent, have been separated out to other design patterns. For an example see the [[User Intent Pattern]].

==Security Considerations==
In general security is not considered in this Design Pattern as security will be provided by the same type of credentials, token and claims as used in any secure implementation. One additional wrinkle that is inserted by a PET provider is that the PET provider must have a sufficient level of trust by the user and the relying party to perform the desired function.

==Interoperability Considerations==
User choice depends critically on each relying party making their request in a manner that can be consistently rendered by the user agent in a form that the user can comprehend that can then be matched to information available from the identity, attribute or privacy-enhancing technology provider. This use case presumes the existence of a set of requirements from the Trustmark selected by the user that provide the promised interoperability and protections for user private data.

= Framework Specific Considerations =
In this use case it is assumed that each identity framework comes with its own Trustmark that the user can understand in terms of the care given to protection of user private data.
== Aerospace and Defense ==
* For this affinity group the user basis is limited to people or services who are well know to the enterprise that issues them with credentials. Those credentials will likely include access authorizations based on the trustworthiness of the user. It is a closed community.
* The specific example is employees, contractors and vendors which are under contract to one of the recognized employers in the A&D industry complying with DoD regulations for protection of secret information.
* Currently, employers may assume that their employment contract allows them to provide employee attributes to any site that the employee voluntarily visits. In the coming years, this assumption might need to be more explicit.

== Health Care ==
* Two specific examples within the health care communities have Identity Ecosystem interest:
** Users of the healthcare system that is open to any person seeking healthcare. It is an open system.
** Providers of the health care system that is open only to persons with credentials appropriate to the care provided. It is a closed system.

The specific interest of the User Experience Committee is the open enrollment of any person looking for health care. This involves every range of user involvement and should be able to accommodate all comers, but may need to send the user to some other location for verification of some attribute as a part of authorizing health care. A user should have the capability to anonymously browse health care provider web sites to determine their qualifications and cost before providing private information. On the other hand the user should expect that health care information will not be released to them until they provide strong proof of identity.

No specific affinity group has been identified for health care users at this point, but there are several NSTIC pilot projects that show ways that users of health care can be accommodated with an IDESG compatible solution.

==References and Citations==
* link to Cranor study on length of time needed to read TOUs / PPs

[[Category:Authentication Design Pattern]]
[[Category:User Experience]]
[[Category:Design Pattern]]
[[Category:Consent]]
[[Category:Profile]]

User Choice Pattern

2021-11-28T19:20:36Z

Tomjones: /* Usability Considerations */

= Design Pattern Metadata =
==Title==
In some ways this is similar to the existing use case that discusses privacy enhancing technology, but the purpose of the pattern is limited to the attributes requested by the RP and the corresponding user experience. Note that a PET provider can be inserted between the RP and the user agent that renders the user experience.

===Design Pattern Lifecycle Status===
{| border="1" padding="2" width="600px"
|Contributed ||bgcolor="SteelBlue"|'''Working Draft'''|| Committee Review || Compilation || Approval || Publication
|-
|colspan=6|This Design Pattern is available for review by the User Experice Committee (UXC) with the goal of refining and completing the Design Pattern, , see [[Identity Design Patterns]] for the current list of design patterns and their status.
|}

===Design Pattern Category===
Privacy, Trust/Assurance, Interoperability

===Contributor===
Tom Jones

== Design Pattern Content ==
The User Choice Design Pattern is meant as a composable object that can be included in any IDESG conformant entity.
==Problem Description (meme)==
User releases only that information to Relying Parties that they wish for purposes that they understand at the time of release. This choice is conveyed in an interchange with an IDESG compliant entity via an object with entries chosen from a '''Taxonomy of Requested Attributes'''. User choices can be cached to avoid cognitive overload.

===When to use this Pattern (Context)===
* Any time a user is asked to provide any personal information. Personal information includes patterns of behavior that could be used narrow the population that contains the user, such as search terms.
* The user device consideration is that the device has a display at least 400 x 800 pixels with a live connection to the internet.
* The IDESG will create an identity ecosystem consisting of multiple trust frameworks that satisfy the needs of specific affinity groups. Since users need to communicate with different affinity groups from time to time, they will typically need to accommodate different trust frameworks during the normal course of daily computer use. Each framework can optionally specify a '''Taxonomy of Requested Attributes''' and a default policy when they differ from the IDEF base policy.
* The RP has a relatively clear set of privacy compliance regulations to follow that can be satisfied by one or more IDEF trust frameworks.
* The RP will support one or more IDEF trust frameworks or providers known to follow IDEF principles for the user to chose from.
* It is expected that each trust framework will come with a set of rules and approved independent labs that can attest to the web site based on the trust frameworks that are supported by the site.
===Relationships with other Design Patterns===
This design pattern assumes the use of a device connected to internet service providers as described in the [[Design Pattern: Common to any Internet Identity Ecosystem]] design pattern.
*[[User Intent Pattern]] is used to acquire the user's intent to allow linking to be passed to the Relying Party.

===Relationships with Use Cases===
The Device Integrity is defined in the "Device Integrity supporting User Authentication Use Case" at [[https://www.idecosystem.org/wiki/Device_Integrity_supporting_User_Authentication]]
===Actors===
# '''User:''' In this case a human being that wants to access services on an internet site and still retain privacy by requesting that the site not retain the user's attributes or provide them to another site without an explicit choice from the user.
# '''User Agent:''' in this case any piece of code that displays a user experience and obtains responses from the user in order to satisfy the privacy concerns of the user and the need for identity and attribute claims by the relying party.
## '''Browser:''' is an entity-independent engine that renders data from an entity, typically in HTML format.
## '''Application''' is typically provided by an entity to render data from it to the user.
# '''IDEF compliant entity''' That is interchanging personal information with a user.
## '''Relying Party (RP):''' A service provider that needs a collection of claims to provide that service. The claims may relate to financial responsibility or other user attributes that are required by regulation to met legal responsibilities. The user experience for RP web sites should improve if they can automate some requests for user's attributes. It is beyond the scope of this Design Pattern to determine whether the RP actually has any justification in requesting any user attribute at all.
## '''Identity or Attribute Provider (IAP):''' contains identities and attributes of users that will be provided on demand in claims that the user can forward to a RP.
## '''Identity Ecosystem:''' a set of services that implement other trust services as required by the rules of that ecosystem. Note that all of the other actors are almost certainly required to function with multiple identity ecosystems; some, but not all, of these ecosystems are expected to be compliant with IDEF trust frameworks.

==Solution==
===Description of the Solution===
# The user establishes an account with one or more IAPs. In this pattern there is no need to distinguish between identity providers and other attribute providers.
# The user accesses a web site which requires identity and attributes claims of some sort to continue to process the user request. That web site then becomes a relying party.
# The RP gives the user a choice from which IDESG framework or provider to provide identity claims.
## In general the identity provider will be a distinct role from the RP where a persistent identifier across multiple interactions is desireable.
##The option of ephemeral connection ID may be provided at the RP's options where anonymous interactions are permitted.
# This request for information is intercepted by privacy enhancing technology or directly by the user agent.
## Determine if the information is available based on the specific requested attributes from the RP.
## Determine if the user has already authorized release to this RP.
## Display any remaining choices to the user to acquire more attributes or release those already available.
## Format the set of requested claims into a response in a way the RP can evaluate the claims.
## Send the response to the RP who has sole responsibility to determine if sufficient identity and attribute claims been provided to authorize the requested access.
## Repeat these steps till the RP is satisfied or one side gives up.

===Taxonomy of an Attribute Request===
It is important that the RP have a taxonomy of requested fields that can be presented to the user within the scope of a single device page. That implies that the taxonomy of requested fields needs to be limited to those items that the user can sensibly be expected to comprehend. It is expected that the language used will support name/value pairs with other attributes such as whether the attribute is mandatory. It is not likely that any list will be complete, the RP can always ask for other information, but this list is intended to be what is released by the user agent in claims. Permissions for release of this information to one RP is likely to be sticky; that is to be released on demand to the same RP, typically for a limited period. (See wiki page on [[Information Sharing Agreement]].)
# Identifier of the RP must be supplied to the user agent in a secure message, such as an EV certificate. This is needed, not only to be sure that the user is sure who is getting the information, but also to allows the future release of the same information to the same RP.
# There is always a tendency for each relying party to determine that their requirement for information is unique and therefore they cannot use a predetermined set of user attributes. This tendency is destructive of user comprehension. The only way to assure that users will understand the options display is to make the basic set of options common for all users. Then a few extension on a web site will at least be in the context of the choice already known and understood by the user.
# To keep the number of choice for the user small it is likely that aggregations of attributes will be required. One example would be the user's street address which is an aggregation of several attribute elements.
# It is also likely that some attribute aggregations can be specified in more or less detail as the user is more or less comfortable in sharing information with the web site. For example the physical location of the user may be limited to a radius of miles, or feet, depending on the requirements of the app. Similarly the home address may be precise, or limited to just the postal (zip) code.
# Message formatted by the RP in a language agreed by the identity framework (the following is just an example)
## Location
### Gross/Fine
## Age
###over/under {13, 18, 21, etc.}
###Birthdate - Highly likely to allow linkage to the real-world user with only a little bit more information - very bad for privacy
## User Identifier
### email {and what it can be used for: messages required by transaction, adds, share with others}
### address {just zip code, or full street address - very bad for privacy}
### phone number {for various access types, home, cell, fax, business, etc.}
## Device Identifier - and perhaps device health

===Error Conditions===
# User does not have credentials acceptable to the relying party.
## Mitigation: The ID ecosystem redirects the user to one or more sources of appropriate credentials that do meet the criteria.
## Mitigation: The relying party redirects the user to one or more Identity Providers or trust frameworks that are acceptable. If a new framework is chosen, that may change the PET to meet those particular requirements.

===Usability Considerations===
One important part of any Design Pattern is the intelligibility of the design to the user. Here it is very important that the user be give only some decisions to address as can easily and comprehensibly be display on the device used. Specifically the amount of explanatory text and the number of choices must be limited by the display capabilities of the smallest devices to be used in the ecosystem as specified above in the "where used" section. See the references section below for the experiences of operating systems that work on [[Smart Phone]]s for an example of a real usable solution. The example of [[Smart Phone]] applications very germane in a internet environment where most web pages download active content into the user's browser (which functions as the user agent in the simplest cases.) The following link provides an image of the application download experience in a [[Smart Phone]] [[http://www.androidcentral.com/look-application-permissions]].

A good review of the complexity that users can face when trying to control the release of data is shown in the following article: "On Facebook, Deciding Who Knows You’re a Dog"
http://www.nytimes.com/2014/01/30/technology/personaltech/on-facebook-deciding-who-knows-youre-a-dog.html?ref=technology&_r=0

Read the report of the IDEF experience committee on use case usability at [[UXC Use Case Mapping]]

===The Paradox of Choice===
* In his book ''The Paradox of Choice – Why More Is Less'' ISBN 0-06-000568-8 (2004-01-06) American psychologist Barry Schwartz makes the case that more choice may not be helpful in making a decision. The user should be given only sufficient choices that have interesting and different consequences, or he will become confused and may not be able to make any decision at all. See the [https://en.wikipedia.org/wiki/The_Paradox_of_Choice Wikipedia entry] for more discussion.
* In a [https://www.wired.com/story/dont-give-users-control-over-data/ Wired article] (2021-11-24) Sandra Metz points out that user control provided by megaliths like FaceBook make a mockery of choice. Until there is effective legal penalties from bad behavior the choice provided by users will be deliberately obscure and hard for the user to understand.<blockquote>Empowering consumers by giving them a say is a noble goal that certainly has a lot of appeal. Yet, in the current data ecosystem, control is far less of a right than it is a responsibility—one that most of us are not equipped to take on. Even if our brains were to magically catch up with the rapidly changing technology landscape, protecting and managing one’s personal data would still be a full-time job.</blockquote>

===Value Proposition===
The most difficult acceptance barrier for most new protocols is the web site of the relying party. If any part of the implementation hinders use of the web site, the feature will not be implemented. If there is no business value to the relying party, it is unlikely that broad adoption will happen. The only way to ensure that any IDESG feature is accepted if for the relying party to see a better user acceptance, or at least a better user experience after adopting the feature. The user choice pattern with the taxonomy of requests provides the opportunity for the RP to include many requests for user private data in an user experience that is shared by many web sites and so will become more familiar and less scary to the user. It will also enable returning users to update their information with no additional user experience elements at all.

==References and Citations==
The Android operating system enforces a system of permissions on the applications loaded into the smart phone to give the user control of the capabilities of the application. Since the deployment of HTML 5 [[http://en.wikipedia.org/wiki/HTML5]] most web pages download applications into user's browsers today, so the example of the Android experience might be very helpful in forming a list of user attributes to be requested in an standard user choice design. Specifically in August 2014 the number of detailed permissions permitted an application in Android was 146 [[http://developer.android.com/reference/android/Manifest.permission.html]] which as been aggregated into 31 [[http://developer.android.com/reference/android/Manifest.permission_group.html]] groups of permissions.

= NSTIC Guiding Principles Considerations =
==Privacy Considerations==
Privacy enhancement is the core of the purpose of this design pattern. One particularly challenging problem is the case of minors under the age of 13 that are covered by COPPA. Those challenges are left for another Design Pattern.

It is known that search terms alone are sufficient in many cases to allow identification of the user. In any service that collects attributes or behaviors of the user over time, only policy enforcement within each entity that handles user information will offer any hope of blocking linkage to the user's real-world identity.

==Security Considerations==
In general security is not considered in this Design Pattern as security will be provided by the same type of credentials, token and claims as used in any secure implementation. One additional wrinkle that is inserted by a PET provider is that the PET provider must have a sufficient level of trust by the user and the relying party to perform the desired function.

==Interoperability Considerations==
User choice depends critically on each relying party making their request in a manner that can be consistently rendered by the user agent in a form that the user can comprehend that can then be matched to information available from the identity, attribute or privacy-enhancing technology provider. This use case presumes the existence of a set of requirements from the RP for user attributes that it requires. Those requirements must have a common meaning within an identity ecosystem or at least within one framework by all parties to the exchange of user information.

= Framework Specific Considerations =
== Aerospace and Defense ==
* The specific example is employees, contractors and vendors which are under contract to one of the recognized employers in the A&D industry complying with DoD regulations for protection of secret information.
* Currently most employers assume that their employment contract allows then to provide employee attributes to any site that the employee voluntarily visits. The assumption is likely to need to be make more explicit in the years to come.

== Health Care ==
Health care is complicated by the requirements of [https://www.hhs.gov/hipaa/index.html HIPAA regulations].
*[[Patient Registration with Distributed Attributes]] discusses the initial establishment of a medical relationship between a patient an a health care provider.
*[[Patient with Lab and Referral Use Case]] discusses subsequent visits with referral to outside providers.
*[[Patient Choice]] wiki page deals with other issues of choice, such as selecting identifiers and access methods or applications.

[[Category:User Experience]]
[[Category:Design Pattern]]
[[Category:Profile]]
[[Category:Authentication Design Pattern]]

User Choice Pattern

2021-11-28T19:17:30Z

Tomjones: /* The Paradox of Choice */

= Design Pattern Metadata =
==Title==
In some ways this is similar to the existing use case that discusses privacy enhancing technology, but the purpose of the pattern is limited to the attributes requested by the RP and the corresponding user experience. Note that a PET provider can be inserted between the RP and the user agent that renders the user experience.

===Design Pattern Lifecycle Status===
{| border="1" padding="2" width="600px"
|Contributed ||bgcolor="SteelBlue"|'''Working Draft'''|| Committee Review || Compilation || Approval || Publication
|-
|colspan=6|This Design Pattern is available for review by the User Experice Committee (UXC) with the goal of refining and completing the Design Pattern, , see [[Identity Design Patterns]] for the current list of design patterns and their status.
|}

===Design Pattern Category===
Privacy, Trust/Assurance, Interoperability

===Contributor===
Tom Jones

== Design Pattern Content ==
The User Choice Design Pattern is meant as a composable object that can be included in any IDESG conformant entity.
==Problem Description (meme)==
User releases only that information to Relying Parties that they wish for purposes that they understand at the time of release. This choice is conveyed in an interchange with an IDESG compliant entity via an object with entries chosen from a '''Taxonomy of Requested Attributes'''. User choices can be cached to avoid cognitive overload.

===When to use this Pattern (Context)===
* Any time a user is asked to provide any personal information. Personal information includes patterns of behavior that could be used narrow the population that contains the user, such as search terms.
* The user device consideration is that the device has a display at least 400 x 800 pixels with a live connection to the internet.
* The IDESG will create an identity ecosystem consisting of multiple trust frameworks that satisfy the needs of specific affinity groups. Since users need to communicate with different affinity groups from time to time, they will typically need to accommodate different trust frameworks during the normal course of daily computer use. Each framework can optionally specify a '''Taxonomy of Requested Attributes''' and a default policy when they differ from the IDEF base policy.
* The RP has a relatively clear set of privacy compliance regulations to follow that can be satisfied by one or more IDEF trust frameworks.
* The RP will support one or more IDEF trust frameworks or providers known to follow IDEF principles for the user to chose from.
* It is expected that each trust framework will come with a set of rules and approved independent labs that can attest to the web site based on the trust frameworks that are supported by the site.
===Relationships with other Design Patterns===
This design pattern assumes the use of a device connected to internet service providers as described in the [[Design Pattern: Common to any Internet Identity Ecosystem]] design pattern.
*[[User Intent Pattern]] is used to acquire the user's intent to allow linking to be passed to the Relying Party.

===Relationships with Use Cases===
The Device Integrity is defined in the "Device Integrity supporting User Authentication Use Case" at [[https://www.idecosystem.org/wiki/Device_Integrity_supporting_User_Authentication]]
===Actors===
# '''User:''' In this case a human being that wants to access services on an internet site and still retain privacy by requesting that the site not retain the user's attributes or provide them to another site without an explicit choice from the user.
# '''User Agent:''' in this case any piece of code that displays a user experience and obtains responses from the user in order to satisfy the privacy concerns of the user and the need for identity and attribute claims by the relying party.
## '''Browser:''' is an entity-independent engine that renders data from an entity, typically in HTML format.
## '''Application''' is typically provided by an entity to render data from it to the user.
# '''IDEF compliant entity''' That is interchanging personal information with a user.
## '''Relying Party (RP):''' A service provider that needs a collection of claims to provide that service. The claims may relate to financial responsibility or other user attributes that are required by regulation to met legal responsibilities. The user experience for RP web sites should improve if they can automate some requests for user's attributes. It is beyond the scope of this Design Pattern to determine whether the RP actually has any justification in requesting any user attribute at all.
## '''Identity or Attribute Provider (IAP):''' contains identities and attributes of users that will be provided on demand in claims that the user can forward to a RP.
## '''Identity Ecosystem:''' a set of services that implement other trust services as required by the rules of that ecosystem. Note that all of the other actors are almost certainly required to function with multiple identity ecosystems; some, but not all, of these ecosystems are expected to be compliant with IDEF trust frameworks.

==Solution==
===Description of the Solution===
# The user establishes an account with one or more IAPs. In this pattern there is no need to distinguish between identity providers and other attribute providers.
# The user accesses a web site which requires identity and attributes claims of some sort to continue to process the user request. That web site then becomes a relying party.
# The RP gives the user a choice from which IDESG framework or provider to provide identity claims.
## In general the identity provider will be a distinct role from the RP where a persistent identifier across multiple interactions is desireable.
##The option of ephemeral connection ID may be provided at the RP's options where anonymous interactions are permitted.
# This request for information is intercepted by privacy enhancing technology or directly by the user agent.
## Determine if the information is available based on the specific requested attributes from the RP.
## Determine if the user has already authorized release to this RP.
## Display any remaining choices to the user to acquire more attributes or release those already available.
## Format the set of requested claims into a response in a way the RP can evaluate the claims.
## Send the response to the RP who has sole responsibility to determine if sufficient identity and attribute claims been provided to authorize the requested access.
## Repeat these steps till the RP is satisfied or one side gives up.

===Taxonomy of an Attribute Request===
It is important that the RP have a taxonomy of requested fields that can be presented to the user within the scope of a single device page. That implies that the taxonomy of requested fields needs to be limited to those items that the user can sensibly be expected to comprehend. It is expected that the language used will support name/value pairs with other attributes such as whether the attribute is mandatory. It is not likely that any list will be complete, the RP can always ask for other information, but this list is intended to be what is released by the user agent in claims. Permissions for release of this information to one RP is likely to be sticky; that is to be released on demand to the same RP, typically for a limited period. (See wiki page on [[Information Sharing Agreement]].)
# Identifier of the RP must be supplied to the user agent in a secure message, such as an EV certificate. This is needed, not only to be sure that the user is sure who is getting the information, but also to allows the future release of the same information to the same RP.
# There is always a tendency for each relying party to determine that their requirement for information is unique and therefore they cannot use a predetermined set of user attributes. This tendency is destructive of user comprehension. The only way to assure that users will understand the options display is to make the basic set of options common for all users. Then a few extension on a web site will at least be in the context of the choice already known and understood by the user.
# To keep the number of choice for the user small it is likely that aggregations of attributes will be required. One example would be the user's street address which is an aggregation of several attribute elements.
# It is also likely that some attribute aggregations can be specified in more or less detail as the user is more or less comfortable in sharing information with the web site. For example the physical location of the user may be limited to a radius of miles, or feet, depending on the requirements of the app. Similarly the home address may be precise, or limited to just the postal (zip) code.
# Message formatted by the RP in a language agreed by the identity framework (the following is just an example)
## Location
### Gross/Fine
## Age
###over/under {13, 18, 21, etc.}
###Birthdate - Highly likely to allow linkage to the real-world user with only a little bit more information - very bad for privacy
## User Identifier
### email {and what it can be used for: messages required by transaction, adds, share with others}
### address {just zip code, or full street address - very bad for privacy}
### phone number {for various access types, home, cell, fax, business, etc.}
## Device Identifier - and perhaps device health

===Error Conditions===
# User does not have credentials acceptable to the relying party.
## Mitigation: The ID ecosystem redirects the user to one or more sources of appropriate credentials that do meet the criteria.
## Mitigation: The relying party redirects the user to one or more Identity Providers or trust frameworks that are acceptable. If a new framework is chosen, that may change the PET to meet those particular requirements.

===Usability Considerations===
One important part of any Design Pattern is the intelligibility of the design to the user. Here it is very important that the user be give only some decisions to address as can easily and comprehensibly be display on the device used. Specifically the amount of explanatory text and the number of choices must be limited by the display capabilities of the smallest devices to be used in the ecosystem as specified above in the "where used" section. See the references section below for the experiences of operating systems that work on [[Smart Phone]]s for an example of a real usable solution. The example of [[Smart Phone]] applications very germane in a internet environment where most web pages download active content into the user's browser (which functions as the user agent in the simplest cases.) The following link provides an image of the application download experience in a [[Smart Phone]] [[http://www.androidcentral.com/look-application-permissions]].

A good review of the complexity that users can face when trying to control the release of data is shown in the following article: "On Facebook, Deciding Who Knows You’re a Dog"
http://www.nytimes.com/2014/01/30/technology/personaltech/on-facebook-deciding-who-knows-youre-a-dog.html?ref=technology&_r=0

Read the report of the IDEF experience committee on use case usability at [[UXC Use Case Mapping]]

--[[User:Tomjones|Tomjones]] ([[User talk:Tomjones|talk]]) 19:17, 28 November 2021 (UTC)===The Paradox of Choice===
* In his book ''The Paradox of Choice – Why More Is Less'' ISBN 0-06-000568-8 (2004-01-06) American psychologist Barry Schwartz makes the case that more choice may not be helpful in making a decision. The user should be given only sufficient choices that have interesting and different consequences, or he will become confused and may not be able to make any decision at all. See the [https://en.wikipedia.org/wiki/The_Paradox_of_Choice Wikipedia entry] for more discussion.
* In a [https://www.wired.com/story/dont-give-users-control-over-data/ Wired article] (2021-11-24) Sandra Metz points out that user control provided by megaliths like FaceBook make a mockery of choice. Until there is effective legal penalties from bad behavior the choice provided by users will be deliberately obscure and hard for the user to understand.<blockquote>Empowering consumers by giving them a say is a noble goal that certainly has a lot of appeal. Yet, in the current data ecosystem, control is far less of a right than it is a responsibility—one that most of us are not equipped to take on. Even if our brains were to magically catch up with the rapidly changing technology landscape, protecting and managing one’s personal data would still be a full-time job.</blockquote>

===Value Proposition===
The most difficult acceptance barrier for most new protocols is the web site of the relying party. If any part of the implementation hinders use of the web site, the feature will not be implemented. If there is no business value to the relying party, it is unlikely that broad adoption will happen. The only way to ensure that any IDESG feature is accepted if for the relying party to see a better user acceptance, or at least a better user experience after adopting the feature. The user choice pattern with the taxonomy of requests provides the opportunity for the RP to include many requests for user private data in an user experience that is shared by many web sites and so will become more familiar and less scary to the user. It will also enable returning users to update their information with no additional user experience elements at all.

==References and Citations==
The Android operating system enforces a system of permissions on the applications loaded into the smart phone to give the user control of the capabilities of the application. Since the deployment of HTML 5 [[http://en.wikipedia.org/wiki/HTML5]] most web pages download applications into user's browsers today, so the example of the Android experience might be very helpful in forming a list of user attributes to be requested in an standard user choice design. Specifically in August 2014 the number of detailed permissions permitted an application in Android was 146 [[http://developer.android.com/reference/android/Manifest.permission.html]] which as been aggregated into 31 [[http://developer.android.com/reference/android/Manifest.permission_group.html]] groups of permissions.

= NSTIC Guiding Principles Considerations =
==Privacy Considerations==
Privacy enhancement is the core of the purpose of this design pattern. One particularly challenging problem is the case of minors under the age of 13 that are covered by COPPA. Those challenges are left for another Design Pattern.

It is known that search terms alone are sufficient in many cases to allow identification of the user. In any service that collects attributes or behaviors of the user over time, only policy enforcement within each entity that handles user information will offer any hope of blocking linkage to the user's real-world identity.

==Security Considerations==
In general security is not considered in this Design Pattern as security will be provided by the same type of credentials, token and claims as used in any secure implementation. One additional wrinkle that is inserted by a PET provider is that the PET provider must have a sufficient level of trust by the user and the relying party to perform the desired function.

==Interoperability Considerations==
User choice depends critically on each relying party making their request in a manner that can be consistently rendered by the user agent in a form that the user can comprehend that can then be matched to information available from the identity, attribute or privacy-enhancing technology provider. This use case presumes the existence of a set of requirements from the RP for user attributes that it requires. Those requirements must have a common meaning within an identity ecosystem or at least within one framework by all parties to the exchange of user information.

= Framework Specific Considerations =
== Aerospace and Defense ==
* The specific example is employees, contractors and vendors which are under contract to one of the recognized employers in the A&D industry complying with DoD regulations for protection of secret information.
* Currently most employers assume that their employment contract allows then to provide employee attributes to any site that the employee voluntarily visits. The assumption is likely to need to be make more explicit in the years to come.

== Health Care ==
Health care is complicated by the requirements of [https://www.hhs.gov/hipaa/index.html HIPAA regulations].
*[[Patient Registration with Distributed Attributes]] discusses the initial establishment of a medical relationship between a patient an a health care provider.
*[[Patient with Lab and Referral Use Case]] discusses subsequent visits with referral to outside providers.
*[[Patient Choice]] wiki page deals with other issues of choice, such as selecting identifiers and access methods or applications.

[[Category:User Experience]]
[[Category:Design Pattern]]
[[Category:Profile]]
[[Category:Authentication Design Pattern]]

User Choice Pattern

2021-11-28T19:06:40Z

Tomjones: /* The Paradox of Choice */

= Design Pattern Metadata =
==Title==
In some ways this is similar to the existing use case that discusses privacy enhancing technology, but the purpose of the pattern is limited to the attributes requested by the RP and the corresponding user experience. Note that a PET provider can be inserted between the RP and the user agent that renders the user experience.

===Design Pattern Lifecycle Status===
{| border="1" padding="2" width="600px"
|Contributed ||bgcolor="SteelBlue"|'''Working Draft'''|| Committee Review || Compilation || Approval || Publication
|-
|colspan=6|This Design Pattern is available for review by the User Experice Committee (UXC) with the goal of refining and completing the Design Pattern, , see [[Identity Design Patterns]] for the current list of design patterns and their status.
|}

===Design Pattern Category===
Privacy, Trust/Assurance, Interoperability

===Contributor===
Tom Jones

== Design Pattern Content ==
The User Choice Design Pattern is meant as a composable object that can be included in any IDESG conformant entity.
==Problem Description (meme)==
User releases only that information to Relying Parties that they wish for purposes that they understand at the time of release. This choice is conveyed in an interchange with an IDESG compliant entity via an object with entries chosen from a '''Taxonomy of Requested Attributes'''. User choices can be cached to avoid cognitive overload.

===When to use this Pattern (Context)===
* Any time a user is asked to provide any personal information. Personal information includes patterns of behavior that could be used narrow the population that contains the user, such as search terms.
* The user device consideration is that the device has a display at least 400 x 800 pixels with a live connection to the internet.
* The IDESG will create an identity ecosystem consisting of multiple trust frameworks that satisfy the needs of specific affinity groups. Since users need to communicate with different affinity groups from time to time, they will typically need to accommodate different trust frameworks during the normal course of daily computer use. Each framework can optionally specify a '''Taxonomy of Requested Attributes''' and a default policy when they differ from the IDEF base policy.
* The RP has a relatively clear set of privacy compliance regulations to follow that can be satisfied by one or more IDEF trust frameworks.
* The RP will support one or more IDEF trust frameworks or providers known to follow IDEF principles for the user to chose from.
* It is expected that each trust framework will come with a set of rules and approved independent labs that can attest to the web site based on the trust frameworks that are supported by the site.
===Relationships with other Design Patterns===
This design pattern assumes the use of a device connected to internet service providers as described in the [[Design Pattern: Common to any Internet Identity Ecosystem]] design pattern.
*[[User Intent Pattern]] is used to acquire the user's intent to allow linking to be passed to the Relying Party.

===Relationships with Use Cases===
The Device Integrity is defined in the "Device Integrity supporting User Authentication Use Case" at [[https://www.idecosystem.org/wiki/Device_Integrity_supporting_User_Authentication]]
===Actors===
# '''User:''' In this case a human being that wants to access services on an internet site and still retain privacy by requesting that the site not retain the user's attributes or provide them to another site without an explicit choice from the user.
# '''User Agent:''' in this case any piece of code that displays a user experience and obtains responses from the user in order to satisfy the privacy concerns of the user and the need for identity and attribute claims by the relying party.
## '''Browser:''' is an entity-independent engine that renders data from an entity, typically in HTML format.
## '''Application''' is typically provided by an entity to render data from it to the user.
# '''IDEF compliant entity''' That is interchanging personal information with a user.
## '''Relying Party (RP):''' A service provider that needs a collection of claims to provide that service. The claims may relate to financial responsibility or other user attributes that are required by regulation to met legal responsibilities. The user experience for RP web sites should improve if they can automate some requests for user's attributes. It is beyond the scope of this Design Pattern to determine whether the RP actually has any justification in requesting any user attribute at all.
## '''Identity or Attribute Provider (IAP):''' contains identities and attributes of users that will be provided on demand in claims that the user can forward to a RP.
## '''Identity Ecosystem:''' a set of services that implement other trust services as required by the rules of that ecosystem. Note that all of the other actors are almost certainly required to function with multiple identity ecosystems; some, but not all, of these ecosystems are expected to be compliant with IDEF trust frameworks.

==Solution==
===Description of the Solution===
# The user establishes an account with one or more IAPs. In this pattern there is no need to distinguish between identity providers and other attribute providers.
# The user accesses a web site which requires identity and attributes claims of some sort to continue to process the user request. That web site then becomes a relying party.
# The RP gives the user a choice from which IDESG framework or provider to provide identity claims.
## In general the identity provider will be a distinct role from the RP where a persistent identifier across multiple interactions is desireable.
##The option of ephemeral connection ID may be provided at the RP's options where anonymous interactions are permitted.
# This request for information is intercepted by privacy enhancing technology or directly by the user agent.
## Determine if the information is available based on the specific requested attributes from the RP.
## Determine if the user has already authorized release to this RP.
## Display any remaining choices to the user to acquire more attributes or release those already available.
## Format the set of requested claims into a response in a way the RP can evaluate the claims.
## Send the response to the RP who has sole responsibility to determine if sufficient identity and attribute claims been provided to authorize the requested access.
## Repeat these steps till the RP is satisfied or one side gives up.

===Taxonomy of an Attribute Request===
It is important that the RP have a taxonomy of requested fields that can be presented to the user within the scope of a single device page. That implies that the taxonomy of requested fields needs to be limited to those items that the user can sensibly be expected to comprehend. It is expected that the language used will support name/value pairs with other attributes such as whether the attribute is mandatory. It is not likely that any list will be complete, the RP can always ask for other information, but this list is intended to be what is released by the user agent in claims. Permissions for release of this information to one RP is likely to be sticky; that is to be released on demand to the same RP, typically for a limited period. (See wiki page on [[Information Sharing Agreement]].)
# Identifier of the RP must be supplied to the user agent in a secure message, such as an EV certificate. This is needed, not only to be sure that the user is sure who is getting the information, but also to allows the future release of the same information to the same RP.
# There is always a tendency for each relying party to determine that their requirement for information is unique and therefore they cannot use a predetermined set of user attributes. This tendency is destructive of user comprehension. The only way to assure that users will understand the options display is to make the basic set of options common for all users. Then a few extension on a web site will at least be in the context of the choice already known and understood by the user.
# To keep the number of choice for the user small it is likely that aggregations of attributes will be required. One example would be the user's street address which is an aggregation of several attribute elements.
# It is also likely that some attribute aggregations can be specified in more or less detail as the user is more or less comfortable in sharing information with the web site. For example the physical location of the user may be limited to a radius of miles, or feet, depending on the requirements of the app. Similarly the home address may be precise, or limited to just the postal (zip) code.
# Message formatted by the RP in a language agreed by the identity framework (the following is just an example)
## Location
### Gross/Fine
## Age
###over/under {13, 18, 21, etc.}
###Birthdate - Highly likely to allow linkage to the real-world user with only a little bit more information - very bad for privacy
## User Identifier
### email {and what it can be used for: messages required by transaction, adds, share with others}
### address {just zip code, or full street address - very bad for privacy}
### phone number {for various access types, home, cell, fax, business, etc.}
## Device Identifier - and perhaps device health

===Error Conditions===
# User does not have credentials acceptable to the relying party.
## Mitigation: The ID ecosystem redirects the user to one or more sources of appropriate credentials that do meet the criteria.
## Mitigation: The relying party redirects the user to one or more Identity Providers or trust frameworks that are acceptable. If a new framework is chosen, that may change the PET to meet those particular requirements.

===Usability Considerations===
One important part of any Design Pattern is the intelligibility of the design to the user. Here it is very important that the user be give only some decisions to address as can easily and comprehensibly be display on the device used. Specifically the amount of explanatory text and the number of choices must be limited by the display capabilities of the smallest devices to be used in the ecosystem as specified above in the "where used" section. See the references section below for the experiences of operating systems that work on [[Smart Phone]]s for an example of a real usable solution. The example of [[Smart Phone]] applications very germane in a internet environment where most web pages download active content into the user's browser (which functions as the user agent in the simplest cases.) The following link provides an image of the application download experience in a [[Smart Phone]] [[http://www.androidcentral.com/look-application-permissions]].

A good review of the complexity that users can face when trying to control the release of data is shown in the following article: "On Facebook, Deciding Who Knows You’re a Dog"
http://www.nytimes.com/2014/01/30/technology/personaltech/on-facebook-deciding-who-knows-youre-a-dog.html?ref=technology&_r=0

Read the report of the IDEF experience committee on use case usability at [[UXC Use Case Mapping]]

===The Paradox of Choice===
* In his book ''The Paradox of Choice – Why More Is Less'' ISBN 0-06-000568-8 (2004-01-06) American psychologist Barry Schwartz makes the case that more choice may not be helpful in making a decision. The user should be given only sufficient choices that have interesting and different consequences, or he will become confused and may not be able to make any decision at all. See the [https://en.wikipedia.org/wiki/The_Paradox_of_Choice Wikipedia entry] for more discussion.
* In a [https://www.wired.com/story/dont-give-users-control-over-data/ Wired article] (2021-11-24) Sandra Metz points out that user control provided by megaliths like FaceBook make a mockery of choice. Until there is effective legal penalties from bad behavior the choice provided by users will be deliberately obscure and hard for the user to understand.

===Value Proposition===
The most difficult acceptance barrier for most new protocols is the web site of the relying party. If any part of the implementation hinders use of the web site, the feature will not be implemented. If there is no business value to the relying party, it is unlikely that broad adoption will happen. The only way to ensure that any IDESG feature is accepted if for the relying party to see a better user acceptance, or at least a better user experience after adopting the feature. The user choice pattern with the taxonomy of requests provides the opportunity for the RP to include many requests for user private data in an user experience that is shared by many web sites and so will become more familiar and less scary to the user. It will also enable returning users to update their information with no additional user experience elements at all.

==References and Citations==
The Android operating system enforces a system of permissions on the applications loaded into the smart phone to give the user control of the capabilities of the application. Since the deployment of HTML 5 [[http://en.wikipedia.org/wiki/HTML5]] most web pages download applications into user's browsers today, so the example of the Android experience might be very helpful in forming a list of user attributes to be requested in an standard user choice design. Specifically in August 2014 the number of detailed permissions permitted an application in Android was 146 [[http://developer.android.com/reference/android/Manifest.permission.html]] which as been aggregated into 31 [[http://developer.android.com/reference/android/Manifest.permission_group.html]] groups of permissions.

= NSTIC Guiding Principles Considerations =
==Privacy Considerations==
Privacy enhancement is the core of the purpose of this design pattern. One particularly challenging problem is the case of minors under the age of 13 that are covered by COPPA. Those challenges are left for another Design Pattern.

It is known that search terms alone are sufficient in many cases to allow identification of the user. In any service that collects attributes or behaviors of the user over time, only policy enforcement within each entity that handles user information will offer any hope of blocking linkage to the user's real-world identity.

==Security Considerations==
In general security is not considered in this Design Pattern as security will be provided by the same type of credentials, token and claims as used in any secure implementation. One additional wrinkle that is inserted by a PET provider is that the PET provider must have a sufficient level of trust by the user and the relying party to perform the desired function.

==Interoperability Considerations==
User choice depends critically on each relying party making their request in a manner that can be consistently rendered by the user agent in a form that the user can comprehend that can then be matched to information available from the identity, attribute or privacy-enhancing technology provider. This use case presumes the existence of a set of requirements from the RP for user attributes that it requires. Those requirements must have a common meaning within an identity ecosystem or at least within one framework by all parties to the exchange of user information.

= Framework Specific Considerations =
== Aerospace and Defense ==
* The specific example is employees, contractors and vendors which are under contract to one of the recognized employers in the A&D industry complying with DoD regulations for protection of secret information.
* Currently most employers assume that their employment contract allows then to provide employee attributes to any site that the employee voluntarily visits. The assumption is likely to need to be make more explicit in the years to come.

== Health Care ==
Health care is complicated by the requirements of [https://www.hhs.gov/hipaa/index.html HIPAA regulations].
*[[Patient Registration with Distributed Attributes]] discusses the initial establishment of a medical relationship between a patient an a health care provider.
*[[Patient with Lab and Referral Use Case]] discusses subsequent visits with referral to outside providers.
*[[Patient Choice]] wiki page deals with other issues of choice, such as selecting identifiers and access methods or applications.

[[Category:User Experience]]
[[Category:Design Pattern]]
[[Category:Profile]]
[[Category:Authentication Design Pattern]]

User Choice Pattern

2021-11-28T19:05:24Z

Tomjones: /* The Paradox of Choice */

= Design Pattern Metadata =
==Title==
In some ways this is similar to the existing use case that discusses privacy enhancing technology, but the purpose of the pattern is limited to the attributes requested by the RP and the corresponding user experience. Note that a PET provider can be inserted between the RP and the user agent that renders the user experience.

===Design Pattern Lifecycle Status===
{| border="1" padding="2" width="600px"
|Contributed ||bgcolor="SteelBlue"|'''Working Draft'''|| Committee Review || Compilation || Approval || Publication
|-
|colspan=6|This Design Pattern is available for review by the User Experice Committee (UXC) with the goal of refining and completing the Design Pattern, , see [[Identity Design Patterns]] for the current list of design patterns and their status.
|}

===Design Pattern Category===
Privacy, Trust/Assurance, Interoperability

===Contributor===
Tom Jones

== Design Pattern Content ==
The User Choice Design Pattern is meant as a composable object that can be included in any IDESG conformant entity.
==Problem Description (meme)==
User releases only that information to Relying Parties that they wish for purposes that they understand at the time of release. This choice is conveyed in an interchange with an IDESG compliant entity via an object with entries chosen from a '''Taxonomy of Requested Attributes'''. User choices can be cached to avoid cognitive overload.

===When to use this Pattern (Context)===
* Any time a user is asked to provide any personal information. Personal information includes patterns of behavior that could be used narrow the population that contains the user, such as search terms.
* The user device consideration is that the device has a display at least 400 x 800 pixels with a live connection to the internet.
* The IDESG will create an identity ecosystem consisting of multiple trust frameworks that satisfy the needs of specific affinity groups. Since users need to communicate with different affinity groups from time to time, they will typically need to accommodate different trust frameworks during the normal course of daily computer use. Each framework can optionally specify a '''Taxonomy of Requested Attributes''' and a default policy when they differ from the IDEF base policy.
* The RP has a relatively clear set of privacy compliance regulations to follow that can be satisfied by one or more IDEF trust frameworks.
* The RP will support one or more IDEF trust frameworks or providers known to follow IDEF principles for the user to chose from.
* It is expected that each trust framework will come with a set of rules and approved independent labs that can attest to the web site based on the trust frameworks that are supported by the site.
===Relationships with other Design Patterns===
This design pattern assumes the use of a device connected to internet service providers as described in the [[Design Pattern: Common to any Internet Identity Ecosystem]] design pattern.
*[[User Intent Pattern]] is used to acquire the user's intent to allow linking to be passed to the Relying Party.

===Relationships with Use Cases===
The Device Integrity is defined in the "Device Integrity supporting User Authentication Use Case" at [[https://www.idecosystem.org/wiki/Device_Integrity_supporting_User_Authentication]]
===Actors===
# '''User:''' In this case a human being that wants to access services on an internet site and still retain privacy by requesting that the site not retain the user's attributes or provide them to another site without an explicit choice from the user.
# '''User Agent:''' in this case any piece of code that displays a user experience and obtains responses from the user in order to satisfy the privacy concerns of the user and the need for identity and attribute claims by the relying party.
## '''Browser:''' is an entity-independent engine that renders data from an entity, typically in HTML format.
## '''Application''' is typically provided by an entity to render data from it to the user.
# '''IDEF compliant entity''' That is interchanging personal information with a user.
## '''Relying Party (RP):''' A service provider that needs a collection of claims to provide that service. The claims may relate to financial responsibility or other user attributes that are required by regulation to met legal responsibilities. The user experience for RP web sites should improve if they can automate some requests for user's attributes. It is beyond the scope of this Design Pattern to determine whether the RP actually has any justification in requesting any user attribute at all.
## '''Identity or Attribute Provider (IAP):''' contains identities and attributes of users that will be provided on demand in claims that the user can forward to a RP.
## '''Identity Ecosystem:''' a set of services that implement other trust services as required by the rules of that ecosystem. Note that all of the other actors are almost certainly required to function with multiple identity ecosystems; some, but not all, of these ecosystems are expected to be compliant with IDEF trust frameworks.

==Solution==
===Description of the Solution===
# The user establishes an account with one or more IAPs. In this pattern there is no need to distinguish between identity providers and other attribute providers.
# The user accesses a web site which requires identity and attributes claims of some sort to continue to process the user request. That web site then becomes a relying party.
# The RP gives the user a choice from which IDESG framework or provider to provide identity claims.
## In general the identity provider will be a distinct role from the RP where a persistent identifier across multiple interactions is desireable.
##The option of ephemeral connection ID may be provided at the RP's options where anonymous interactions are permitted.
# This request for information is intercepted by privacy enhancing technology or directly by the user agent.
## Determine if the information is available based on the specific requested attributes from the RP.
## Determine if the user has already authorized release to this RP.
## Display any remaining choices to the user to acquire more attributes or release those already available.
## Format the set of requested claims into a response in a way the RP can evaluate the claims.
## Send the response to the RP who has sole responsibility to determine if sufficient identity and attribute claims been provided to authorize the requested access.
## Repeat these steps till the RP is satisfied or one side gives up.

===Taxonomy of an Attribute Request===
It is important that the RP have a taxonomy of requested fields that can be presented to the user within the scope of a single device page. That implies that the taxonomy of requested fields needs to be limited to those items that the user can sensibly be expected to comprehend. It is expected that the language used will support name/value pairs with other attributes such as whether the attribute is mandatory. It is not likely that any list will be complete, the RP can always ask for other information, but this list is intended to be what is released by the user agent in claims. Permissions for release of this information to one RP is likely to be sticky; that is to be released on demand to the same RP, typically for a limited period. (See wiki page on [[Information Sharing Agreement]].)
# Identifier of the RP must be supplied to the user agent in a secure message, such as an EV certificate. This is needed, not only to be sure that the user is sure who is getting the information, but also to allows the future release of the same information to the same RP.
# There is always a tendency for each relying party to determine that their requirement for information is unique and therefore they cannot use a predetermined set of user attributes. This tendency is destructive of user comprehension. The only way to assure that users will understand the options display is to make the basic set of options common for all users. Then a few extension on a web site will at least be in the context of the choice already known and understood by the user.
# To keep the number of choice for the user small it is likely that aggregations of attributes will be required. One example would be the user's street address which is an aggregation of several attribute elements.
# It is also likely that some attribute aggregations can be specified in more or less detail as the user is more or less comfortable in sharing information with the web site. For example the physical location of the user may be limited to a radius of miles, or feet, depending on the requirements of the app. Similarly the home address may be precise, or limited to just the postal (zip) code.
# Message formatted by the RP in a language agreed by the identity framework (the following is just an example)
## Location
### Gross/Fine
## Age
###over/under {13, 18, 21, etc.}
###Birthdate - Highly likely to allow linkage to the real-world user with only a little bit more information - very bad for privacy
## User Identifier
### email {and what it can be used for: messages required by transaction, adds, share with others}
### address {just zip code, or full street address - very bad for privacy}
### phone number {for various access types, home, cell, fax, business, etc.}
## Device Identifier - and perhaps device health

===Error Conditions===
# User does not have credentials acceptable to the relying party.
## Mitigation: The ID ecosystem redirects the user to one or more sources of appropriate credentials that do meet the criteria.
## Mitigation: The relying party redirects the user to one or more Identity Providers or trust frameworks that are acceptable. If a new framework is chosen, that may change the PET to meet those particular requirements.

===Usability Considerations===
One important part of any Design Pattern is the intelligibility of the design to the user. Here it is very important that the user be give only some decisions to address as can easily and comprehensibly be display on the device used. Specifically the amount of explanatory text and the number of choices must be limited by the display capabilities of the smallest devices to be used in the ecosystem as specified above in the "where used" section. See the references section below for the experiences of operating systems that work on [[Smart Phone]]s for an example of a real usable solution. The example of [[Smart Phone]] applications very germane in a internet environment where most web pages download active content into the user's browser (which functions as the user agent in the simplest cases.) The following link provides an image of the application download experience in a [[Smart Phone]] [[http://www.androidcentral.com/look-application-permissions]].

A good review of the complexity that users can face when trying to control the release of data is shown in the following article: "On Facebook, Deciding Who Knows You’re a Dog"
http://www.nytimes.com/2014/01/30/technology/personaltech/on-facebook-deciding-who-knows-youre-a-dog.html?ref=technology&_r=0

Read the report of the IDEF experience committee on use case usability at [[UXC Use Case Mapping]]

===The Paradox of Choice===
* In his book ''The Paradox of Choice – Why More Is Less'' ISBN 0-06-000568-8 (2004-01-06) American psychologist Barry Schwartz makes the case that more choice may not be helpful in making a decision. The user should be given only sufficient choices that have interesting and different consequences, or he will become confused and may not be able to make any decision at all. See the [https://en.wikipedia.org/wiki/The_Paradox_of_Choice Wikipedia entry] for more discussion.
* In a [https://www.wired.com/story/dont-give-users-control-over-data/ Wired article] (2-21=11=24) Santra Metz points out that user control provided by megaliths like FaceBook make a mockery of choice. Until there is effective legal penalties from bad behavior the choice provided by users will be deliberately obscure and hard for the user to understand.

===Value Proposition===
The most difficult acceptance barrier for most new protocols is the web site of the relying party. If any part of the implementation hinders use of the web site, the feature will not be implemented. If there is no business value to the relying party, it is unlikely that broad adoption will happen. The only way to ensure that any IDESG feature is accepted if for the relying party to see a better user acceptance, or at least a better user experience after adopting the feature. The user choice pattern with the taxonomy of requests provides the opportunity for the RP to include many requests for user private data in an user experience that is shared by many web sites and so will become more familiar and less scary to the user. It will also enable returning users to update their information with no additional user experience elements at all.

==References and Citations==
The Android operating system enforces a system of permissions on the applications loaded into the smart phone to give the user control of the capabilities of the application. Since the deployment of HTML 5 [[http://en.wikipedia.org/wiki/HTML5]] most web pages download applications into user's browsers today, so the example of the Android experience might be very helpful in forming a list of user attributes to be requested in an standard user choice design. Specifically in August 2014 the number of detailed permissions permitted an application in Android was 146 [[http://developer.android.com/reference/android/Manifest.permission.html]] which as been aggregated into 31 [[http://developer.android.com/reference/android/Manifest.permission_group.html]] groups of permissions.

= NSTIC Guiding Principles Considerations =
==Privacy Considerations==
Privacy enhancement is the core of the purpose of this design pattern. One particularly challenging problem is the case of minors under the age of 13 that are covered by COPPA. Those challenges are left for another Design Pattern.

It is known that search terms alone are sufficient in many cases to allow identification of the user. In any service that collects attributes or behaviors of the user over time, only policy enforcement within each entity that handles user information will offer any hope of blocking linkage to the user's real-world identity.

==Security Considerations==
In general security is not considered in this Design Pattern as security will be provided by the same type of credentials, token and claims as used in any secure implementation. One additional wrinkle that is inserted by a PET provider is that the PET provider must have a sufficient level of trust by the user and the relying party to perform the desired function.

==Interoperability Considerations==
User choice depends critically on each relying party making their request in a manner that can be consistently rendered by the user agent in a form that the user can comprehend that can then be matched to information available from the identity, attribute or privacy-enhancing technology provider. This use case presumes the existence of a set of requirements from the RP for user attributes that it requires. Those requirements must have a common meaning within an identity ecosystem or at least within one framework by all parties to the exchange of user information.

= Framework Specific Considerations =
== Aerospace and Defense ==
* The specific example is employees, contractors and vendors which are under contract to one of the recognized employers in the A&D industry complying with DoD regulations for protection of secret information.
* Currently most employers assume that their employment contract allows then to provide employee attributes to any site that the employee voluntarily visits. The assumption is likely to need to be make more explicit in the years to come.

== Health Care ==
Health care is complicated by the requirements of [https://www.hhs.gov/hipaa/index.html HIPAA regulations].
*[[Patient Registration with Distributed Attributes]] discusses the initial establishment of a medical relationship between a patient an a health care provider.
*[[Patient with Lab and Referral Use Case]] discusses subsequent visits with referral to outside providers.
*[[Patient Choice]] wiki page deals with other issues of choice, such as selecting identifiers and access methods or applications.

[[Category:User Experience]]
[[Category:Design Pattern]]
[[Category:Profile]]
[[Category:Authentication Design Pattern]]

User Choice Pattern

2021-11-28T18:47:59Z

Tomjones: /* The Paradox of Choice */

= Design Pattern Metadata =
==Title==
In some ways this is similar to the existing use case that discusses privacy enhancing technology, but the purpose of the pattern is limited to the attributes requested by the RP and the corresponding user experience. Note that a PET provider can be inserted between the RP and the user agent that renders the user experience.

===Design Pattern Lifecycle Status===
{| border="1" padding="2" width="600px"
|Contributed ||bgcolor="SteelBlue"|'''Working Draft'''|| Committee Review || Compilation || Approval || Publication
|-
|colspan=6|This Design Pattern is available for review by the User Experice Committee (UXC) with the goal of refining and completing the Design Pattern, , see [[Identity Design Patterns]] for the current list of design patterns and their status.
|}

===Design Pattern Category===
Privacy, Trust/Assurance, Interoperability

===Contributor===
Tom Jones

== Design Pattern Content ==
The User Choice Design Pattern is meant as a composable object that can be included in any IDESG conformant entity.
==Problem Description (meme)==
User releases only that information to Relying Parties that they wish for purposes that they understand at the time of release. This choice is conveyed in an interchange with an IDESG compliant entity via an object with entries chosen from a '''Taxonomy of Requested Attributes'''. User choices can be cached to avoid cognitive overload.

===When to use this Pattern (Context)===
* Any time a user is asked to provide any personal information. Personal information includes patterns of behavior that could be used narrow the population that contains the user, such as search terms.
* The user device consideration is that the device has a display at least 400 x 800 pixels with a live connection to the internet.
* The IDESG will create an identity ecosystem consisting of multiple trust frameworks that satisfy the needs of specific affinity groups. Since users need to communicate with different affinity groups from time to time, they will typically need to accommodate different trust frameworks during the normal course of daily computer use. Each framework can optionally specify a '''Taxonomy of Requested Attributes''' and a default policy when they differ from the IDEF base policy.
* The RP has a relatively clear set of privacy compliance regulations to follow that can be satisfied by one or more IDEF trust frameworks.
* The RP will support one or more IDEF trust frameworks or providers known to follow IDEF principles for the user to chose from.
* It is expected that each trust framework will come with a set of rules and approved independent labs that can attest to the web site based on the trust frameworks that are supported by the site.
===Relationships with other Design Patterns===
This design pattern assumes the use of a device connected to internet service providers as described in the [[Design Pattern: Common to any Internet Identity Ecosystem]] design pattern.
*[[User Intent Pattern]] is used to acquire the user's intent to allow linking to be passed to the Relying Party.

===Relationships with Use Cases===
The Device Integrity is defined in the "Device Integrity supporting User Authentication Use Case" at [[https://www.idecosystem.org/wiki/Device_Integrity_supporting_User_Authentication]]
===Actors===
# '''User:''' In this case a human being that wants to access services on an internet site and still retain privacy by requesting that the site not retain the user's attributes or provide them to another site without an explicit choice from the user.
# '''User Agent:''' in this case any piece of code that displays a user experience and obtains responses from the user in order to satisfy the privacy concerns of the user and the need for identity and attribute claims by the relying party.
## '''Browser:''' is an entity-independent engine that renders data from an entity, typically in HTML format.
## '''Application''' is typically provided by an entity to render data from it to the user.
# '''IDEF compliant entity''' That is interchanging personal information with a user.
## '''Relying Party (RP):''' A service provider that needs a collection of claims to provide that service. The claims may relate to financial responsibility or other user attributes that are required by regulation to met legal responsibilities. The user experience for RP web sites should improve if they can automate some requests for user's attributes. It is beyond the scope of this Design Pattern to determine whether the RP actually has any justification in requesting any user attribute at all.
## '''Identity or Attribute Provider (IAP):''' contains identities and attributes of users that will be provided on demand in claims that the user can forward to a RP.
## '''Identity Ecosystem:''' a set of services that implement other trust services as required by the rules of that ecosystem. Note that all of the other actors are almost certainly required to function with multiple identity ecosystems; some, but not all, of these ecosystems are expected to be compliant with IDEF trust frameworks.

==Solution==
===Description of the Solution===
# The user establishes an account with one or more IAPs. In this pattern there is no need to distinguish between identity providers and other attribute providers.
# The user accesses a web site which requires identity and attributes claims of some sort to continue to process the user request. That web site then becomes a relying party.
# The RP gives the user a choice from which IDESG framework or provider to provide identity claims.
## In general the identity provider will be a distinct role from the RP where a persistent identifier across multiple interactions is desireable.
##The option of ephemeral connection ID may be provided at the RP's options where anonymous interactions are permitted.
# This request for information is intercepted by privacy enhancing technology or directly by the user agent.
## Determine if the information is available based on the specific requested attributes from the RP.
## Determine if the user has already authorized release to this RP.
## Display any remaining choices to the user to acquire more attributes or release those already available.
## Format the set of requested claims into a response in a way the RP can evaluate the claims.
## Send the response to the RP who has sole responsibility to determine if sufficient identity and attribute claims been provided to authorize the requested access.
## Repeat these steps till the RP is satisfied or one side gives up.

===Taxonomy of an Attribute Request===
It is important that the RP have a taxonomy of requested fields that can be presented to the user within the scope of a single device page. That implies that the taxonomy of requested fields needs to be limited to those items that the user can sensibly be expected to comprehend. It is expected that the language used will support name/value pairs with other attributes such as whether the attribute is mandatory. It is not likely that any list will be complete, the RP can always ask for other information, but this list is intended to be what is released by the user agent in claims. Permissions for release of this information to one RP is likely to be sticky; that is to be released on demand to the same RP, typically for a limited period. (See wiki page on [[Information Sharing Agreement]].)
# Identifier of the RP must be supplied to the user agent in a secure message, such as an EV certificate. This is needed, not only to be sure that the user is sure who is getting the information, but also to allows the future release of the same information to the same RP.
# There is always a tendency for each relying party to determine that their requirement for information is unique and therefore they cannot use a predetermined set of user attributes. This tendency is destructive of user comprehension. The only way to assure that users will understand the options display is to make the basic set of options common for all users. Then a few extension on a web site will at least be in the context of the choice already known and understood by the user.
# To keep the number of choice for the user small it is likely that aggregations of attributes will be required. One example would be the user's street address which is an aggregation of several attribute elements.
# It is also likely that some attribute aggregations can be specified in more or less detail as the user is more or less comfortable in sharing information with the web site. For example the physical location of the user may be limited to a radius of miles, or feet, depending on the requirements of the app. Similarly the home address may be precise, or limited to just the postal (zip) code.
# Message formatted by the RP in a language agreed by the identity framework (the following is just an example)
## Location
### Gross/Fine
## Age
###over/under {13, 18, 21, etc.}
###Birthdate - Highly likely to allow linkage to the real-world user with only a little bit more information - very bad for privacy
## User Identifier
### email {and what it can be used for: messages required by transaction, adds, share with others}
### address {just zip code, or full street address - very bad for privacy}
### phone number {for various access types, home, cell, fax, business, etc.}
## Device Identifier - and perhaps device health

===Error Conditions===
# User does not have credentials acceptable to the relying party.
## Mitigation: The ID ecosystem redirects the user to one or more sources of appropriate credentials that do meet the criteria.
## Mitigation: The relying party redirects the user to one or more Identity Providers or trust frameworks that are acceptable. If a new framework is chosen, that may change the PET to meet those particular requirements.

===Usability Considerations===
One important part of any Design Pattern is the intelligibility of the design to the user. Here it is very important that the user be give only some decisions to address as can easily and comprehensibly be display on the device used. Specifically the amount of explanatory text and the number of choices must be limited by the display capabilities of the smallest devices to be used in the ecosystem as specified above in the "where used" section. See the references section below for the experiences of operating systems that work on [[Smart Phone]]s for an example of a real usable solution. The example of [[Smart Phone]] applications very germane in a internet environment where most web pages download active content into the user's browser (which functions as the user agent in the simplest cases.) The following link provides an image of the application download experience in a [[Smart Phone]] [[http://www.androidcentral.com/look-application-permissions]].

A good review of the complexity that users can face when trying to control the release of data is shown in the following article: "On Facebook, Deciding Who Knows You’re a Dog"
http://www.nytimes.com/2014/01/30/technology/personaltech/on-facebook-deciding-who-knows-youre-a-dog.html?ref=technology&_r=0

Read the report of the IDEF experience committee on use case usability at [[UXC Use Case Mapping]]

===The Paradox of Choice===
* In his book ''The Paradox of Choice – Why More Is Less'' ISBN 0-06-000568-8 (2004-01-06) American psychologist Barry Schwartz makes the case that more choice may not be helpful in making a decision. The user should be given only sufficient choices that have interesting and different consequences, or he will become confused and may not be able to make any decision at all. See the [https://en.wikipedia.org/wiki/The_Paradox_of_Choice Wikipedia entry] for more discussion.
* In a Wired article<ref>https://www.wired.com/story/dont-give-users-control-over-data/</ref>

===Value Proposition===
The most difficult acceptance barrier for most new protocols is the web site of the relying party. If any part of the implementation hinders use of the web site, the feature will not be implemented. If there is no business value to the relying party, it is unlikely that broad adoption will happen. The only way to ensure that any IDESG feature is accepted if for the relying party to see a better user acceptance, or at least a better user experience after adopting the feature. The user choice pattern with the taxonomy of requests provides the opportunity for the RP to include many requests for user private data in an user experience that is shared by many web sites and so will become more familiar and less scary to the user. It will also enable returning users to update their information with no additional user experience elements at all.

==References and Citations==
The Android operating system enforces a system of permissions on the applications loaded into the smart phone to give the user control of the capabilities of the application. Since the deployment of HTML 5 [[http://en.wikipedia.org/wiki/HTML5]] most web pages download applications into user's browsers today, so the example of the Android experience might be very helpful in forming a list of user attributes to be requested in an standard user choice design. Specifically in August 2014 the number of detailed permissions permitted an application in Android was 146 [[http://developer.android.com/reference/android/Manifest.permission.html]] which as been aggregated into 31 [[http://developer.android.com/reference/android/Manifest.permission_group.html]] groups of permissions.

= NSTIC Guiding Principles Considerations =
==Privacy Considerations==
Privacy enhancement is the core of the purpose of this design pattern. One particularly challenging problem is the case of minors under the age of 13 that are covered by COPPA. Those challenges are left for another Design Pattern.

It is known that search terms alone are sufficient in many cases to allow identification of the user. In any service that collects attributes or behaviors of the user over time, only policy enforcement within each entity that handles user information will offer any hope of blocking linkage to the user's real-world identity.

==Security Considerations==
In general security is not considered in this Design Pattern as security will be provided by the same type of credentials, token and claims as used in any secure implementation. One additional wrinkle that is inserted by a PET provider is that the PET provider must have a sufficient level of trust by the user and the relying party to perform the desired function.

==Interoperability Considerations==
User choice depends critically on each relying party making their request in a manner that can be consistently rendered by the user agent in a form that the user can comprehend that can then be matched to information available from the identity, attribute or privacy-enhancing technology provider. This use case presumes the existence of a set of requirements from the RP for user attributes that it requires. Those requirements must have a common meaning within an identity ecosystem or at least within one framework by all parties to the exchange of user information.

= Framework Specific Considerations =
== Aerospace and Defense ==
* The specific example is employees, contractors and vendors which are under contract to one of the recognized employers in the A&D industry complying with DoD regulations for protection of secret information.
* Currently most employers assume that their employment contract allows then to provide employee attributes to any site that the employee voluntarily visits. The assumption is likely to need to be make more explicit in the years to come.

== Health Care ==
Health care is complicated by the requirements of [https://www.hhs.gov/hipaa/index.html HIPAA regulations].
*[[Patient Registration with Distributed Attributes]] discusses the initial establishment of a medical relationship between a patient an a health care provider.
*[[Patient with Lab and Referral Use Case]] discusses subsequent visits with referral to outside providers.
*[[Patient Choice]] wiki page deals with other issues of choice, such as selecting identifiers and access methods or applications.

[[Category:User Experience]]
[[Category:Design Pattern]]
[[Category:Profile]]
[[Category:Authentication Design Pattern]]

User Choice Pattern

2021-11-28T18:40:33Z

Tomjones: /* Status */

= Design Pattern Metadata =
==Title==
In some ways this is similar to the existing use case that discusses privacy enhancing technology, but the purpose of the pattern is limited to the attributes requested by the RP and the corresponding user experience. Note that a PET provider can be inserted between the RP and the user agent that renders the user experience.

===Design Pattern Lifecycle Status===
{| border="1" padding="2" width="600px"
|Contributed ||bgcolor="SteelBlue"|'''Working Draft'''|| Committee Review || Compilation || Approval || Publication
|-
|colspan=6|This Design Pattern is available for review by the User Experice Committee (UXC) with the goal of refining and completing the Design Pattern, , see [[Identity Design Patterns]] for the current list of design patterns and their status.
|}

===Design Pattern Category===
Privacy, Trust/Assurance, Interoperability

===Contributor===
Tom Jones

== Design Pattern Content ==
The User Choice Design Pattern is meant as a composable object that can be included in any IDESG conformant entity.
==Problem Description (meme)==
User releases only that information to Relying Parties that they wish for purposes that they understand at the time of release. This choice is conveyed in an interchange with an IDESG compliant entity via an object with entries chosen from a '''Taxonomy of Requested Attributes'''. User choices can be cached to avoid cognitive overload.

===When to use this Pattern (Context)===
* Any time a user is asked to provide any personal information. Personal information includes patterns of behavior that could be used narrow the population that contains the user, such as search terms.
* The user device consideration is that the device has a display at least 400 x 800 pixels with a live connection to the internet.
* The IDESG will create an identity ecosystem consisting of multiple trust frameworks that satisfy the needs of specific affinity groups. Since users need to communicate with different affinity groups from time to time, they will typically need to accommodate different trust frameworks during the normal course of daily computer use. Each framework can optionally specify a '''Taxonomy of Requested Attributes''' and a default policy when they differ from the IDEF base policy.
* The RP has a relatively clear set of privacy compliance regulations to follow that can be satisfied by one or more IDEF trust frameworks.
* The RP will support one or more IDEF trust frameworks or providers known to follow IDEF principles for the user to chose from.
* It is expected that each trust framework will come with a set of rules and approved independent labs that can attest to the web site based on the trust frameworks that are supported by the site.
===Relationships with other Design Patterns===
This design pattern assumes the use of a device connected to internet service providers as described in the [[Design Pattern: Common to any Internet Identity Ecosystem]] design pattern.
*[[User Intent Pattern]] is used to acquire the user's intent to allow linking to be passed to the Relying Party.

===Relationships with Use Cases===
The Device Integrity is defined in the "Device Integrity supporting User Authentication Use Case" at [[https://www.idecosystem.org/wiki/Device_Integrity_supporting_User_Authentication]]
===Actors===
# '''User:''' In this case a human being that wants to access services on an internet site and still retain privacy by requesting that the site not retain the user's attributes or provide them to another site without an explicit choice from the user.
# '''User Agent:''' in this case any piece of code that displays a user experience and obtains responses from the user in order to satisfy the privacy concerns of the user and the need for identity and attribute claims by the relying party.
## '''Browser:''' is an entity-independent engine that renders data from an entity, typically in HTML format.
## '''Application''' is typically provided by an entity to render data from it to the user.
# '''IDEF compliant entity''' That is interchanging personal information with a user.
## '''Relying Party (RP):''' A service provider that needs a collection of claims to provide that service. The claims may relate to financial responsibility or other user attributes that are required by regulation to met legal responsibilities. The user experience for RP web sites should improve if they can automate some requests for user's attributes. It is beyond the scope of this Design Pattern to determine whether the RP actually has any justification in requesting any user attribute at all.
## '''Identity or Attribute Provider (IAP):''' contains identities and attributes of users that will be provided on demand in claims that the user can forward to a RP.
## '''Identity Ecosystem:''' a set of services that implement other trust services as required by the rules of that ecosystem. Note that all of the other actors are almost certainly required to function with multiple identity ecosystems; some, but not all, of these ecosystems are expected to be compliant with IDEF trust frameworks.

==Solution==
===Description of the Solution===
# The user establishes an account with one or more IAPs. In this pattern there is no need to distinguish between identity providers and other attribute providers.
# The user accesses a web site which requires identity and attributes claims of some sort to continue to process the user request. That web site then becomes a relying party.
# The RP gives the user a choice from which IDESG framework or provider to provide identity claims.
## In general the identity provider will be a distinct role from the RP where a persistent identifier across multiple interactions is desireable.
##The option of ephemeral connection ID may be provided at the RP's options where anonymous interactions are permitted.
# This request for information is intercepted by privacy enhancing technology or directly by the user agent.
## Determine if the information is available based on the specific requested attributes from the RP.
## Determine if the user has already authorized release to this RP.
## Display any remaining choices to the user to acquire more attributes or release those already available.
## Format the set of requested claims into a response in a way the RP can evaluate the claims.
## Send the response to the RP who has sole responsibility to determine if sufficient identity and attribute claims been provided to authorize the requested access.
## Repeat these steps till the RP is satisfied or one side gives up.

===Taxonomy of an Attribute Request===
It is important that the RP have a taxonomy of requested fields that can be presented to the user within the scope of a single device page. That implies that the taxonomy of requested fields needs to be limited to those items that the user can sensibly be expected to comprehend. It is expected that the language used will support name/value pairs with other attributes such as whether the attribute is mandatory. It is not likely that any list will be complete, the RP can always ask for other information, but this list is intended to be what is released by the user agent in claims. Permissions for release of this information to one RP is likely to be sticky; that is to be released on demand to the same RP, typically for a limited period. (See wiki page on [[Information Sharing Agreement]].)
# Identifier of the RP must be supplied to the user agent in a secure message, such as an EV certificate. This is needed, not only to be sure that the user is sure who is getting the information, but also to allows the future release of the same information to the same RP.
# There is always a tendency for each relying party to determine that their requirement for information is unique and therefore they cannot use a predetermined set of user attributes. This tendency is destructive of user comprehension. The only way to assure that users will understand the options display is to make the basic set of options common for all users. Then a few extension on a web site will at least be in the context of the choice already known and understood by the user.
# To keep the number of choice for the user small it is likely that aggregations of attributes will be required. One example would be the user's street address which is an aggregation of several attribute elements.
# It is also likely that some attribute aggregations can be specified in more or less detail as the user is more or less comfortable in sharing information with the web site. For example the physical location of the user may be limited to a radius of miles, or feet, depending on the requirements of the app. Similarly the home address may be precise, or limited to just the postal (zip) code.
# Message formatted by the RP in a language agreed by the identity framework (the following is just an example)
## Location
### Gross/Fine
## Age
###over/under {13, 18, 21, etc.}
###Birthdate - Highly likely to allow linkage to the real-world user with only a little bit more information - very bad for privacy
## User Identifier
### email {and what it can be used for: messages required by transaction, adds, share with others}
### address {just zip code, or full street address - very bad for privacy}
### phone number {for various access types, home, cell, fax, business, etc.}
## Device Identifier - and perhaps device health

===Error Conditions===
# User does not have credentials acceptable to the relying party.
## Mitigation: The ID ecosystem redirects the user to one or more sources of appropriate credentials that do meet the criteria.
## Mitigation: The relying party redirects the user to one or more Identity Providers or trust frameworks that are acceptable. If a new framework is chosen, that may change the PET to meet those particular requirements.

===Usability Considerations===
One important part of any Design Pattern is the intelligibility of the design to the user. Here it is very important that the user be give only some decisions to address as can easily and comprehensibly be display on the device used. Specifically the amount of explanatory text and the number of choices must be limited by the display capabilities of the smallest devices to be used in the ecosystem as specified above in the "where used" section. See the references section below for the experiences of operating systems that work on [[Smart Phone]]s for an example of a real usable solution. The example of [[Smart Phone]] applications very germane in a internet environment where most web pages download active content into the user's browser (which functions as the user agent in the simplest cases.) The following link provides an image of the application download experience in a [[Smart Phone]] [[http://www.androidcentral.com/look-application-permissions]].

A good review of the complexity that users can face when trying to control the release of data is shown in the following article: "On Facebook, Deciding Who Knows You’re a Dog"
http://www.nytimes.com/2014/01/30/technology/personaltech/on-facebook-deciding-who-knows-youre-a-dog.html?ref=technology&_r=0

Read the report of the IDEF experience committee on use case usability at [[UXC Use Case Mapping]]

===The Paradox of Choice===
In his book ''The Paradox of Choice – Why More Is Less'' ISBN 0-06-000568-8 (2004-01-06) American psychologist Barry Schwartz makes the case that more choice may not be helpful in making a decision. The user should be given only sufficient choices that have interesting and different consequences, or he will become confused and may not be able to make any decision at all. See the [https://en.wikipedia.org/wiki/The_Paradox_of_Choice Wikipedia entry] for more discussion.

===Value Proposition===
The most difficult acceptance barrier for most new protocols is the web site of the relying party. If any part of the implementation hinders use of the web site, the feature will not be implemented. If there is no business value to the relying party, it is unlikely that broad adoption will happen. The only way to ensure that any IDESG feature is accepted if for the relying party to see a better user acceptance, or at least a better user experience after adopting the feature. The user choice pattern with the taxonomy of requests provides the opportunity for the RP to include many requests for user private data in an user experience that is shared by many web sites and so will become more familiar and less scary to the user. It will also enable returning users to update their information with no additional user experience elements at all.

==References and Citations==
The Android operating system enforces a system of permissions on the applications loaded into the smart phone to give the user control of the capabilities of the application. Since the deployment of HTML 5 [[http://en.wikipedia.org/wiki/HTML5]] most web pages download applications into user's browsers today, so the example of the Android experience might be very helpful in forming a list of user attributes to be requested in an standard user choice design. Specifically in August 2014 the number of detailed permissions permitted an application in Android was 146 [[http://developer.android.com/reference/android/Manifest.permission.html]] which as been aggregated into 31 [[http://developer.android.com/reference/android/Manifest.permission_group.html]] groups of permissions.

= NSTIC Guiding Principles Considerations =
==Privacy Considerations==
Privacy enhancement is the core of the purpose of this design pattern. One particularly challenging problem is the case of minors under the age of 13 that are covered by COPPA. Those challenges are left for another Design Pattern.

It is known that search terms alone are sufficient in many cases to allow identification of the user. In any service that collects attributes or behaviors of the user over time, only policy enforcement within each entity that handles user information will offer any hope of blocking linkage to the user's real-world identity.

==Security Considerations==
In general security is not considered in this Design Pattern as security will be provided by the same type of credentials, token and claims as used in any secure implementation. One additional wrinkle that is inserted by a PET provider is that the PET provider must have a sufficient level of trust by the user and the relying party to perform the desired function.

==Interoperability Considerations==
User choice depends critically on each relying party making their request in a manner that can be consistently rendered by the user agent in a form that the user can comprehend that can then be matched to information available from the identity, attribute or privacy-enhancing technology provider. This use case presumes the existence of a set of requirements from the RP for user attributes that it requires. Those requirements must have a common meaning within an identity ecosystem or at least within one framework by all parties to the exchange of user information.

= Framework Specific Considerations =
== Aerospace and Defense ==
* The specific example is employees, contractors and vendors which are under contract to one of the recognized employers in the A&D industry complying with DoD regulations for protection of secret information.
* Currently most employers assume that their employment contract allows then to provide employee attributes to any site that the employee voluntarily visits. The assumption is likely to need to be make more explicit in the years to come.

== Health Care ==
Health care is complicated by the requirements of [https://www.hhs.gov/hipaa/index.html HIPAA regulations].
*[[Patient Registration with Distributed Attributes]] discusses the initial establishment of a medical relationship between a patient an a health care provider.
*[[Patient with Lab and Referral Use Case]] discusses subsequent visits with referral to outside providers.
*[[Patient Choice]] wiki page deals with other issues of choice, such as selecting identifiers and access methods or applications.

[[Category:User Experience]]
[[Category:Design Pattern]]
[[Category:Profile]]
[[Category:Authentication Design Pattern]]

User Choice Pattern

2021-11-28T18:39:45Z

Tomjones:

= Design Pattern Metadata =
==Title==
In some ways this is similar to the existing use case that discusses privacy enhancing technology, but the purpose of the pattern is limited to the attributes requested by the RP and the corresponding user experience. Note that a PET provider can be inserted between the RP and the user agent that renders the user experience.

==Status==
===Design Pattern Lifecycle Status===
{| border="1" padding="2" width="600px"
|Contributed ||bgcolor="SteelBlue"|'''Working Draft'''|| Committee Review || Compilation || Approval || Publication
|-
|colspan=6|This Design Pattern is available for review by the User Experice Committee (UXC) with the goal of refining and completing the Design Pattern, , see [[Identity Design Patterns]] for the current list of design patterns and their status.
|}

===Design Pattern Category===
Privacy, Trust/Assurance, Interoperability

===Contributor===
Tom Jones

== Design Pattern Content ==
The User Choice Design Pattern is meant as a composable object that can be included in any IDESG conformant entity.
==Problem Description (meme)==
User releases only that information to Relying Parties that they wish for purposes that they understand at the time of release. This choice is conveyed in an interchange with an IDESG compliant entity via an object with entries chosen from a '''Taxonomy of Requested Attributes'''. User choices can be cached to avoid cognitive overload.

===When to use this Pattern (Context)===
* Any time a user is asked to provide any personal information. Personal information includes patterns of behavior that could be used narrow the population that contains the user, such as search terms.
* The user device consideration is that the device has a display at least 400 x 800 pixels with a live connection to the internet.
* The IDESG will create an identity ecosystem consisting of multiple trust frameworks that satisfy the needs of specific affinity groups. Since users need to communicate with different affinity groups from time to time, they will typically need to accommodate different trust frameworks during the normal course of daily computer use. Each framework can optionally specify a '''Taxonomy of Requested Attributes''' and a default policy when they differ from the IDEF base policy.
* The RP has a relatively clear set of privacy compliance regulations to follow that can be satisfied by one or more IDEF trust frameworks.
* The RP will support one or more IDEF trust frameworks or providers known to follow IDEF principles for the user to chose from.
* It is expected that each trust framework will come with a set of rules and approved independent labs that can attest to the web site based on the trust frameworks that are supported by the site.
===Relationships with other Design Patterns===
This design pattern assumes the use of a device connected to internet service providers as described in the [[Design Pattern: Common to any Internet Identity Ecosystem]] design pattern.
*[[User Intent Pattern]] is used to acquire the user's intent to allow linking to be passed to the Relying Party.

===Relationships with Use Cases===
The Device Integrity is defined in the "Device Integrity supporting User Authentication Use Case" at [[https://www.idecosystem.org/wiki/Device_Integrity_supporting_User_Authentication]]
===Actors===
# '''User:''' In this case a human being that wants to access services on an internet site and still retain privacy by requesting that the site not retain the user's attributes or provide them to another site without an explicit choice from the user.
# '''User Agent:''' in this case any piece of code that displays a user experience and obtains responses from the user in order to satisfy the privacy concerns of the user and the need for identity and attribute claims by the relying party.
## '''Browser:''' is an entity-independent engine that renders data from an entity, typically in HTML format.
## '''Application''' is typically provided by an entity to render data from it to the user.
# '''IDEF compliant entity''' That is interchanging personal information with a user.
## '''Relying Party (RP):''' A service provider that needs a collection of claims to provide that service. The claims may relate to financial responsibility or other user attributes that are required by regulation to met legal responsibilities. The user experience for RP web sites should improve if they can automate some requests for user's attributes. It is beyond the scope of this Design Pattern to determine whether the RP actually has any justification in requesting any user attribute at all.
## '''Identity or Attribute Provider (IAP):''' contains identities and attributes of users that will be provided on demand in claims that the user can forward to a RP.
## '''Identity Ecosystem:''' a set of services that implement other trust services as required by the rules of that ecosystem. Note that all of the other actors are almost certainly required to function with multiple identity ecosystems; some, but not all, of these ecosystems are expected to be compliant with IDEF trust frameworks.

==Solution==
===Description of the Solution===
# The user establishes an account with one or more IAPs. In this pattern there is no need to distinguish between identity providers and other attribute providers.
# The user accesses a web site which requires identity and attributes claims of some sort to continue to process the user request. That web site then becomes a relying party.
# The RP gives the user a choice from which IDESG framework or provider to provide identity claims.
## In general the identity provider will be a distinct role from the RP where a persistent identifier across multiple interactions is desireable.
##The option of ephemeral connection ID may be provided at the RP's options where anonymous interactions are permitted.
# This request for information is intercepted by privacy enhancing technology or directly by the user agent.
## Determine if the information is available based on the specific requested attributes from the RP.
## Determine if the user has already authorized release to this RP.
## Display any remaining choices to the user to acquire more attributes or release those already available.
## Format the set of requested claims into a response in a way the RP can evaluate the claims.
## Send the response to the RP who has sole responsibility to determine if sufficient identity and attribute claims been provided to authorize the requested access.
## Repeat these steps till the RP is satisfied or one side gives up.

===Taxonomy of an Attribute Request===
It is important that the RP have a taxonomy of requested fields that can be presented to the user within the scope of a single device page. That implies that the taxonomy of requested fields needs to be limited to those items that the user can sensibly be expected to comprehend. It is expected that the language used will support name/value pairs with other attributes such as whether the attribute is mandatory. It is not likely that any list will be complete, the RP can always ask for other information, but this list is intended to be what is released by the user agent in claims. Permissions for release of this information to one RP is likely to be sticky; that is to be released on demand to the same RP, typically for a limited period. (See wiki page on [[Information Sharing Agreement]].)
# Identifier of the RP must be supplied to the user agent in a secure message, such as an EV certificate. This is needed, not only to be sure that the user is sure who is getting the information, but also to allows the future release of the same information to the same RP.
# There is always a tendency for each relying party to determine that their requirement for information is unique and therefore they cannot use a predetermined set of user attributes. This tendency is destructive of user comprehension. The only way to assure that users will understand the options display is to make the basic set of options common for all users. Then a few extension on a web site will at least be in the context of the choice already known and understood by the user.
# To keep the number of choice for the user small it is likely that aggregations of attributes will be required. One example would be the user's street address which is an aggregation of several attribute elements.
# It is also likely that some attribute aggregations can be specified in more or less detail as the user is more or less comfortable in sharing information with the web site. For example the physical location of the user may be limited to a radius of miles, or feet, depending on the requirements of the app. Similarly the home address may be precise, or limited to just the postal (zip) code.
# Message formatted by the RP in a language agreed by the identity framework (the following is just an example)
## Location
### Gross/Fine
## Age
###over/under {13, 18, 21, etc.}
###Birthdate - Highly likely to allow linkage to the real-world user with only a little bit more information - very bad for privacy
## User Identifier
### email {and what it can be used for: messages required by transaction, adds, share with others}
### address {just zip code, or full street address - very bad for privacy}
### phone number {for various access types, home, cell, fax, business, etc.}
## Device Identifier - and perhaps device health

===Error Conditions===
# User does not have credentials acceptable to the relying party.
## Mitigation: The ID ecosystem redirects the user to one or more sources of appropriate credentials that do meet the criteria.
## Mitigation: The relying party redirects the user to one or more Identity Providers or trust frameworks that are acceptable. If a new framework is chosen, that may change the PET to meet those particular requirements.

===Usability Considerations===
One important part of any Design Pattern is the intelligibility of the design to the user. Here it is very important that the user be give only some decisions to address as can easily and comprehensibly be display on the device used. Specifically the amount of explanatory text and the number of choices must be limited by the display capabilities of the smallest devices to be used in the ecosystem as specified above in the "where used" section. See the references section below for the experiences of operating systems that work on [[Smart Phone]]s for an example of a real usable solution. The example of [[Smart Phone]] applications very germane in a internet environment where most web pages download active content into the user's browser (which functions as the user agent in the simplest cases.) The following link provides an image of the application download experience in a [[Smart Phone]] [[http://www.androidcentral.com/look-application-permissions]].

A good review of the complexity that users can face when trying to control the release of data is shown in the following article: "On Facebook, Deciding Who Knows You’re a Dog"
http://www.nytimes.com/2014/01/30/technology/personaltech/on-facebook-deciding-who-knows-youre-a-dog.html?ref=technology&_r=0

Read the report of the IDEF experience committee on use case usability at [[UXC Use Case Mapping]]

===The Paradox of Choice===
In his book ''The Paradox of Choice – Why More Is Less'' ISBN 0-06-000568-8 (2004-01-06) American psychologist Barry Schwartz makes the case that more choice may not be helpful in making a decision. The user should be given only sufficient choices that have interesting and different consequences, or he will become confused and may not be able to make any decision at all. See the [https://en.wikipedia.org/wiki/The_Paradox_of_Choice Wikipedia entry] for more discussion.

===Value Proposition===
The most difficult acceptance barrier for most new protocols is the web site of the relying party. If any part of the implementation hinders use of the web site, the feature will not be implemented. If there is no business value to the relying party, it is unlikely that broad adoption will happen. The only way to ensure that any IDESG feature is accepted if for the relying party to see a better user acceptance, or at least a better user experience after adopting the feature. The user choice pattern with the taxonomy of requests provides the opportunity for the RP to include many requests for user private data in an user experience that is shared by many web sites and so will become more familiar and less scary to the user. It will also enable returning users to update their information with no additional user experience elements at all.

==References and Citations==
The Android operating system enforces a system of permissions on the applications loaded into the smart phone to give the user control of the capabilities of the application. Since the deployment of HTML 5 [[http://en.wikipedia.org/wiki/HTML5]] most web pages download applications into user's browsers today, so the example of the Android experience might be very helpful in forming a list of user attributes to be requested in an standard user choice design. Specifically in August 2014 the number of detailed permissions permitted an application in Android was 146 [[http://developer.android.com/reference/android/Manifest.permission.html]] which as been aggregated into 31 [[http://developer.android.com/reference/android/Manifest.permission_group.html]] groups of permissions.

= NSTIC Guiding Principles Considerations =
==Privacy Considerations==
Privacy enhancement is the core of the purpose of this design pattern. One particularly challenging problem is the case of minors under the age of 13 that are covered by COPPA. Those challenges are left for another Design Pattern.

It is known that search terms alone are sufficient in many cases to allow identification of the user. In any service that collects attributes or behaviors of the user over time, only policy enforcement within each entity that handles user information will offer any hope of blocking linkage to the user's real-world identity.

==Security Considerations==
In general security is not considered in this Design Pattern as security will be provided by the same type of credentials, token and claims as used in any secure implementation. One additional wrinkle that is inserted by a PET provider is that the PET provider must have a sufficient level of trust by the user and the relying party to perform the desired function.

==Interoperability Considerations==
User choice depends critically on each relying party making their request in a manner that can be consistently rendered by the user agent in a form that the user can comprehend that can then be matched to information available from the identity, attribute or privacy-enhancing technology provider. This use case presumes the existence of a set of requirements from the RP for user attributes that it requires. Those requirements must have a common meaning within an identity ecosystem or at least within one framework by all parties to the exchange of user information.

= Framework Specific Considerations =
== Aerospace and Defense ==
* The specific example is employees, contractors and vendors which are under contract to one of the recognized employers in the A&D industry complying with DoD regulations for protection of secret information.
* Currently most employers assume that their employment contract allows then to provide employee attributes to any site that the employee voluntarily visits. The assumption is likely to need to be make more explicit in the years to come.

== Health Care ==
Health care is complicated by the requirements of [https://www.hhs.gov/hipaa/index.html HIPAA regulations].
*[[Patient Registration with Distributed Attributes]] discusses the initial establishment of a medical relationship between a patient an a health care provider.
*[[Patient with Lab and Referral Use Case]] discusses subsequent visits with referral to outside providers.
*[[Patient Choice]] wiki page deals with other issues of choice, such as selecting identifiers and access methods or applications.

[[Category:User Experience]]
[[Category:Design Pattern]]
[[Category:Profile]]
[[Category:Authentication Design Pattern]]

Mobile Driver's License in Healthcare

2021-11-13T05:23:19Z

Tomjones: /* Issues */

== Full Title==
Use case for the mobile driver's license as identity proofing credential in healthcare telemedicine.
===Prepared by===
Kantara Healthcare Identity Assurance Work Group

==Context==
The mobile driver's license makes many new possibilities available. This scenario is one (or two) of them.
===Goal===
To enable the enrollment of a remote patient with a healthcare identifier and [https://tcwiki.azurewebsites.net/index.php?title=EHR Electronic Health Record (EHR)] which is accessible by the patient or other proxy.

===Actors===
#Actor: Patient
#Actor: Proxy is used here to mean any person that can help the patient get registered. It could be a patient, spouse, nursing home personnel, public health professional or similar.
#Actor: Healthcare intake personnel and potentially the physician for creating followup actions by the patient.

==Preconditions==
* The patient is in need of healthcare using telemedicine and is not currently known to the practice.
* The patient has access to a mobile device that can authenticate the user and communicate to the physician or pratice.
===Trigger===
The Patient has an appointment that is their very first one via their computer.

==Scenarios==
Primary Scenario:
# Patient receives notice of appointment and instructions for online registration, or in person if she wants to risk it.
# Patient has a mobile driver's license (MDL) and doesn't want to travel to the doctor's office, which is why she chose telemedicine in the first place.
# Patient has an insurance card that is machine readable.
# Patient has a mobile wallet that holds the MDL and can take a picture of the insurance card.
# Patient navigates to the telemedicine web site which can send a message to her wallet to provide the mdl and insurance card as an image.
# Her wallet understands that an image of some sort is required and helps with the image capture.
# The data required from the MDL, the image capture and potential other data is presented to the user as a consent screen.
# The patient chooses to send the data to the telemedicine web site.
# The visit with the physician can start immediately, or when the physician becomes available.
Bonus capability.
# The patient is asked for prior health history and is able to navigate to her PCP and get a QR code that can be included in the message to the telemedicine site which can get the history data.
# The patient has a wallet that can authenticate the user's presence and allows the user to enter their existing driver's card as a machine-readable image.

Secondary Scenario:
# Patient schedules a lab visit after the telemedicine session is completed.

Tertiary Scenario:
# The patient's grandchild acts on her behalf as an access proxy.

==Successful Outcome==
# The patient is correctly matched to their electronic health record.
# The patient has a successful telemedicine experience, receives a set of reports, is schedules for a lab test and immunization at the local pharmacy.
# Follow up procedures are created and sent to her smartphone and give her notices when she must take medicine or other procedures.

==Unsuccessful Outcome==
# Not all of the patient's records are available on-line and some action in the real-world is required to get them altogether.
# The Telemedical connection fails or is not of sufficient quality for the physician to complete the examination.
# The patient feels that the quality of care was not sufficient to meet their needs.

==Privacy Concerns==
* The EHR may release more information that is required for the current visit.
* The patient may be in close quarters with others that should not hear the results of the session.

==Issues==
# The patient is one of the 19% of the population w/o a smart phone. Perhaps her grandchild can help with that.
# Getting the wallet into the patient's smart phone or lap top may prove to be challenging.
# The patient is not comfortable with technology.
# Who determines what data from the MDL is sent to the EHR? (e.g., the healthcare community specs or explicit user consent)?
# Is the driver's license ID number included in any way?
# Is a picture required for patient record matching to the person on the telemedicine call.
# Is fraud one of the threats to be addressed within the scope of the recommendation?

==References==
This use case was updated on 2021-11-11.

* [[Mobile Driver's License]] on this wiki.
* [[State Issued ID for Healthcare]] on this wiki.

[[Category:Profile]]
[[Category:Health]]
[[Category:Use Cases]]

Mobile Driver's License in Healthcare

2021-11-13T05:19:09Z

Tomjones: /* References */

== Full Title==
Use case for the mobile driver's license as identity proofing credential in healthcare telemedicine.
===Prepared by===
Kantara Healthcare Identity Assurance Work Group

==Context==
The mobile driver's license makes many new possibilities available. This scenario is one (or two) of them.
===Goal===
To enable the enrollment of a remote patient with a healthcare identifier and [https://tcwiki.azurewebsites.net/index.php?title=EHR Electronic Health Record (EHR)] which is accessible by the patient or other proxy.

===Actors===
#Actor: Patient
#Actor: Proxy is used here to mean any person that can help the patient get registered. It could be a patient, spouse, nursing home personnel, public health professional or similar.
#Actor: Healthcare intake personnel and potentially the physician for creating followup actions by the patient.

==Preconditions==
* The patient is in need of healthcare using telemedicine and is not currently known to the practice.
* The patient has access to a mobile device that can authenticate the user and communicate to the physician or pratice.
===Trigger===
The Patient has an appointment that is their very first one via their computer.

==Scenarios==
Primary Scenario:
# Patient receives notice of appointment and instructions for online registration, or in person if she wants to risk it.
# Patient has a mobile driver's license (MDL) and doesn't want to travel to the doctor's office, which is why she chose telemedicine in the first place.
# Patient has an insurance card that is machine readable.
# Patient has a mobile wallet that holds the MDL and can take a picture of the insurance card.
# Patient navigates to the telemedicine web site which can send a message to her wallet to provide the mdl and insurance card as an image.
# Her wallet understands that an image of some sort is required and helps with the image capture.
# The data required from the MDL, the image capture and potential other data is presented to the user as a consent screen.
# The patient chooses to send the data to the telemedicine web site.
# The visit with the physician can start immediately, or when the physician becomes available.
Bonus capability.
# The patient is asked for prior health history and is able to navigate to her PCP and get a QR code that can be included in the message to the telemedicine site which can get the history data.
# The patient has a wallet that can authenticate the user's presence and allows the user to enter their existing driver's card as a machine-readable image.

Secondary Scenario:
# Patient schedules a lab visit after the telemedicine session is completed.

Tertiary Scenario:
# The patient's grandchild acts on her behalf as an access proxy.

==Successful Outcome==
# The patient is correctly matched to their electronic health record.
# The patient has a successful telemedicine experience, receives a set of reports, is schedules for a lab test and immunization at the local pharmacy.
# Follow up procedures are created and sent to her smartphone and give her notices when she must take medicine or other procedures.

==Unsuccessful Outcome==
# Not all of the patient's records are available on-line and some action in the real-world is required to get them altogether.
# The Telemedical connection fails or is not of sufficient quality for the physician to complete the examination.
# The patient feels that the quality of care was not sufficient to meet their needs.

==Issues==
# The patient is one of the 19% of the population w/o a smart phone. Perhaps her grandchild can help with that.
# Getting the wallet into the patient's smart phone or lap top may prove to be challenging.
# The patient is not comfortable with technology.
# Who determines what data from the MDL is sent to the EHR? (e.g., the healthcare community specs or explicit user consent)?
# Is the driver's license ID number included in any way?
# Is a picture required in all cases.
# Is fraud a part of the working group's remit.

==References==
This use case was updated on 2021-11-11.

* [[Mobile Driver's License]] on this wiki.
* [[State Issued ID for Healthcare]] on this wiki.

[[Category:Profile]]
[[Category:Health]]
[[Category:Use Cases]]

Mobile Driver's License in Healthcare

2021-11-13T05:18:25Z

Tomjones:

== Full Title==
Use case for the mobile driver's license as identity proofing credential in healthcare telemedicine.
===Prepared by===
Kantara Healthcare Identity Assurance Work Group

==Context==
The mobile driver's license makes many new possibilities available. This scenario is one (or two) of them.
===Goal===
To enable the enrollment of a remote patient with a healthcare identifier and [https://tcwiki.azurewebsites.net/index.php?title=EHR Electronic Health Record (EHR)] which is accessible by the patient or other proxy.

===Actors===
#Actor: Patient
#Actor: Proxy is used here to mean any person that can help the patient get registered. It could be a patient, spouse, nursing home personnel, public health professional or similar.
#Actor: Healthcare intake personnel and potentially the physician for creating followup actions by the patient.

==Preconditions==
* The patient is in need of healthcare using telemedicine and is not currently known to the practice.
* The patient has access to a mobile device that can authenticate the user and communicate to the physician or pratice.
===Trigger===
The Patient has an appointment that is their very first one via their computer.

==Scenarios==
Primary Scenario:
# Patient receives notice of appointment and instructions for online registration, or in person if she wants to risk it.
# Patient has a mobile driver's license (MDL) and doesn't want to travel to the doctor's office, which is why she chose telemedicine in the first place.
# Patient has an insurance card that is machine readable.
# Patient has a mobile wallet that holds the MDL and can take a picture of the insurance card.
# Patient navigates to the telemedicine web site which can send a message to her wallet to provide the mdl and insurance card as an image.
# Her wallet understands that an image of some sort is required and helps with the image capture.
# The data required from the MDL, the image capture and potential other data is presented to the user as a consent screen.
# The patient chooses to send the data to the telemedicine web site.
# The visit with the physician can start immediately, or when the physician becomes available.
Bonus capability.
# The patient is asked for prior health history and is able to navigate to her PCP and get a QR code that can be included in the message to the telemedicine site which can get the history data.
# The patient has a wallet that can authenticate the user's presence and allows the user to enter their existing driver's card as a machine-readable image.

Secondary Scenario:
# Patient schedules a lab visit after the telemedicine session is completed.

Tertiary Scenario:
# The patient's grandchild acts on her behalf as an access proxy.

==Successful Outcome==
# The patient is correctly matched to their electronic health record.
# The patient has a successful telemedicine experience, receives a set of reports, is schedules for a lab test and immunization at the local pharmacy.
# Follow up procedures are created and sent to her smartphone and give her notices when she must take medicine or other procedures.

==Unsuccessful Outcome==
# Not all of the patient's records are available on-line and some action in the real-world is required to get them altogether.
# The Telemedical connection fails or is not of sufficient quality for the physician to complete the examination.
# The patient feels that the quality of care was not sufficient to meet their needs.

==Issues==
# The patient is one of the 19% of the population w/o a smart phone. Perhaps her grandchild can help with that.
# Getting the wallet into the patient's smart phone or lap top may prove to be challenging.
# The patient is not comfortable with technology.
# Who determines what data from the MDL is sent to the EHR? (e.g., the healthcare community specs or explicit user consent)?
# Is the driver's license ID number included in any way?
# Is a picture required in all cases.
# Is fraud a part of the working group's remit.

==References==
* [[Mobile Driver's License]] on this wiki.
* [[State Issued ID for Healthcare]] on this wiki.

[[Category:Profile]]
[[Category:Health]]
[[Category:Use Cases]]

Mobile Driver's License in Healthcare

2021-11-13T05:12:22Z

Tomjones: /* Open Questions */

== Full Title==
Use case for the mobile driver's license as identity proofing credential in healthcare telemedicine.
===Prepared by===
Kantara Healthcare Identity Assurance Work Group

==Context==
The mobile driver's license makes many new possibilities available. This scenario is one (or two) of them.
===Goal===
To enable the enrollment of a remote patient with a healthcare identifier and [https://tcwiki.azurewebsites.net/index.php?title=EHR Electronic Health Record (EHR)] which is accessible by the patient or other proxy.

===Actors===
#Actor: Patient
#Actor: Proxy is used here to mean any person that can help the patient get registered. It could be a patient, spouse, nursing home personnel, public health professional or similar.
#Actor: Healthcare intake personnel and potentially the physician for creating followup actions by the patient.

==Preconditions==
* The patient is in need of healthcare using telemedicine and is not currently known to the practice.
* The patient has access to a mobile device that can authenticate the user and communicate to the physician or pratice.
===Trigger===
The Patient has an appointment that is their very first one via their computer.

==Scenarios==
Primary Scenario:
# Patient receives notice of appointment and instructions for online registration, or in person if she wants to risk it.
# Patient has a mobile driver's license (MDL) and doesn't want to travel to the doctor's office, which is why she chose telemedicine in the first place.
# Patient has an insurance card that is machine readable.
# Patient has a mobile wallet that holds the MDL and can take a picture of the insurance card.
# Patient navigates to the telemedicine web site which can send a message to her wallet to provide the mdl and insurance card as an image.
# Her wallet understands that an image of some sort is required and helps with the image capture.
# The data required from the MDL, the image capture and potential other data is presented to the user as a consent screen.
# The patient chooses to send the data to the telemedicine web site.
# The visit with the physician can start immediately, or when the physician becomes available.
Bonus capability.
# The patient is asked for prior health history and is able to navigate to her PCP and get a QR code that can be included in the message to the telemedicine site which can get the history data.
# The patient has a wallet that can authenticate the user's presence and allows the user to enter their existing driver's card as a machine readable image.

Secondary Scenario:
# Patient schedules a lab visit after the telemedicine session is completed.

Tertiary Scenario:
# The patient's grandchild acts on her behalf as an access proxy.

==Problems==
# The patient is one of the 19% of the population w/o a smart phone. Perhaps her grandchild can help with that.
# Getting the wallet into the patients smart phone or lap top may prove to be challenging.
# The patient is not comfortable with technology.

==Issues==
# Who determines what data from the MDL is sent to the EHR? (eg. the healthcare community specs or explicit user consent)?
# Is the driver's license ID number included in any way?
# Is a picture required in all cases.
# Is fraud a part of the working group's remit.

==Outcome==
# The patient is correctly matched to their electronic health record.
# The patient has a successful telemedicine experience, receives a set of reports, is schedules for a lab test and immunization at the local pharmacy.
# Follow up procedures are created and sent to her smartphone and give her notices when she must take medicine or other procedures.

==References==
* [[Mobile Driver's License]] on this wiki.
* [[State Issued ID for Healthcare]] on this wiki.

[[Category:Profile]]
[[Category:Health]]
[[Category:Use Cases]]

Mobile Driver's License in Healthcare

2021-11-13T05:11:09Z

Tomjones: /* Trigger */

== Full Title==
Use case for the mobile driver's license as identity proofing credential in healthcare telemedicine.
===Prepared by===
Kantara Healthcare Identity Assurance Work Group

==Context==
The mobile driver's license makes many new possibilities available. This scenario is one (or two) of them.
===Goal===
To enable the enrollment of a remote patient with a healthcare identifier and [https://tcwiki.azurewebsites.net/index.php?title=EHR Electronic Health Record (EHR)] which is accessible by the patient or other proxy.

===Actors===
#Actor: Patient
#Actor: Proxy is used here to mean any person that can help the patient get registered. It could be a patient, spouse, nursing home personnel, public health professional or similar.
#Actor: Healthcare intake personnel and potentially the physician for creating followup actions by the patient.

==Preconditions==
* The patient is in need of healthcare using telemedicine and is not currently known to the practice.
* The patient has access to a mobile device that can authenticate the user and communicate to the physician or pratice.
===Trigger===
The Patient has an appointment that is their very first one via their computer.

==Scenarios==
Primary Scenario:
# Patient receives notice of appointment and instructions for online registration, or in person if she wants to risk it.
# Patient has a mobile driver's license (MDL) and doesn't want to travel to the doctor's office, which is why she chose telemedicine in the first place.
# Patient has an insurance card that is machine readable.
# Patient has a mobile wallet that holds the MDL and can take a picture of the insurance card.
# Patient navigates to the telemedicine web site which can send a message to her wallet to provide the mdl and insurance card as an image.
# Her wallet understands that an image of some sort is required and helps with the image capture.
# The data required from the MDL, the image capture and potential other data is presented to the user as a consent screen.
# The patient chooses to send the data to the telemedicine web site.
# The visit with the physician can start immediately, or when the physician becomes available.
Bonus capability.
# The patient is asked for prior health history and is able to navigate to her PCP and get a QR code that can be included in the message to the telemedicine site which can get the history data.
# The patient has a wallet that can authenticate the user's presence and allows the user to enter their existing driver's card as a machine readable image.

Secondary Scenario:
# Patient schedules a lab visit after the telemedicine session is completed.

Tertiary Scenario:
# The patient's grandchild acts on her behalf as an access proxy.

==Problems==
# The patient is one of the 19% of the population w/o a smart phone. Perhaps her grandchild can help with that.
# Getting the wallet into the patients smart phone or lap top may prove to be challenging.
# The patient is not comfortable with technology.

==Open Questions==
# Who determines what data from the MDL is sent to the EHR? (eg. the healthcare community specs or explicit user consent)?
# Is the driver's license ID number included in any way?
# Is a picture required in all cases.
# Is fraud a part of the working group's remit.

==Outcome==
# The patient is correctly matched to their electronic health record.
# The patient has a successful telemedicine experience, receives a set of reports, is schedules for a lab test and immunization at the local pharmacy.
# Follow up procedures are created and sent to her smartphone and give her notices when she must take medicine or other procedures.

==References==
* [[Mobile Driver's License]] on this wiki.
* [[State Issued ID for Healthcare]] on this wiki.

[[Category:Profile]]
[[Category:Health]]
[[Category:Use Cases]]

Mobile Driver's License in Healthcare

2021-11-13T05:10:16Z

Tomjones: /* Preconditions */

== Full Title==
Use case for the mobile driver's license as identity proofing credential in healthcare telemedicine.
===Prepared by===
Kantara Healthcare Identity Assurance Work Group

==Context==
The mobile driver's license makes many new possibilities available. This scenario is one (or two) of them.
===Goal===
To enable the enrollment of a remote patient with a healthcare identifier and [https://tcwiki.azurewebsites.net/index.php?title=EHR Electronic Health Record (EHR)] which is accessible by the patient or other proxy.

===Actors===
#Actor: Patient
#Actor: Proxy is used here to mean any person that can help the patient get registered. It could be a patient, spouse, nursing home personnel, public health professional or similar.
#Actor: Healthcare intake personnel and potentially the physician for creating followup actions by the patient.

==Preconditions==
* The patient is in need of healthcare using telemedicine and is not currently known to the practice.
* The patient has access to a mobile device that can authenticate the user and communicate to the physician or pratice.
===Trigger===
The Patient has an appointment that was referred by their primary care physician (PCP).

==Scenarios==
Primary Scenario:
# Patient receives notice of appointment and instructions for online registration, or in person if she wants to risk it.
# Patient has a mobile driver's license (MDL) and doesn't want to travel to the doctor's office, which is why she chose telemedicine in the first place.
# Patient has an insurance card that is machine readable.
# Patient has a mobile wallet that holds the MDL and can take a picture of the insurance card.
# Patient navigates to the telemedicine web site which can send a message to her wallet to provide the mdl and insurance card as an image.
# Her wallet understands that an image of some sort is required and helps with the image capture.
# The data required from the MDL, the image capture and potential other data is presented to the user as a consent screen.
# The patient chooses to send the data to the telemedicine web site.
# The visit with the physician can start immediately, or when the physician becomes available.
Bonus capability.
# The patient is asked for prior health history and is able to navigate to her PCP and get a QR code that can be included in the message to the telemedicine site which can get the history data.
# The patient has a wallet that can authenticate the user's presence and allows the user to enter their existing driver's card as a machine readable image.

Secondary Scenario:
# Patient schedules a lab visit after the telemedicine session is completed.

Tertiary Scenario:
# The patient's grandchild acts on her behalf as an access proxy.

==Problems==
# The patient is one of the 19% of the population w/o a smart phone. Perhaps her grandchild can help with that.
# Getting the wallet into the patients smart phone or lap top may prove to be challenging.
# The patient is not comfortable with technology.

==Open Questions==
# Who determines what data from the MDL is sent to the EHR? (eg. the healthcare community specs or explicit user consent)?
# Is the driver's license ID number included in any way?
# Is a picture required in all cases.
# Is fraud a part of the working group's remit.

==Outcome==
# The patient is correctly matched to their electronic health record.
# The patient has a successful telemedicine experience, receives a set of reports, is schedules for a lab test and immunization at the local pharmacy.
# Follow up procedures are created and sent to her smartphone and give her notices when she must take medicine or other procedures.

==References==
* [[Mobile Driver's License]] on this wiki.
* [[State Issued ID for Healthcare]] on this wiki.

[[Category:Profile]]
[[Category:Health]]
[[Category:Use Cases]]

Patient Choice

2021-10-01T01:41:58Z

Tomjones: /* Problems */

==Full Title==
The options that a patient should have in accessing and sharing their [https://tcwiki.azurewebsites.net/index.php?title=PHI Protected Health Information (PHI)] with trusted medical providers.
===Source===
The Federated Identifiers for Resilient Ecosystems Work Group of the Kantara Initiative.
=== Last updated===
2021-04-30 (HIPAA changes can introduce new threats)

==Context==
* For more context see the wiki page [[Native Apps for US Healthcare]] which looks at the apps that control access to user secrets in hardware. This page considers web apps as well.
* The major context for this page is an environment where user's private data is treated like a commodity to be bought and sold. These two postings in the Sunday New York Times on 2020-01-26 demonstrate conclusively that a [[Trustworthy Healthcare Ecosystem]] requires more attention to the handling of healthcare data that is common at this time:
** The report on '''The Secretive Company That Might End Privacy as we Know it''' received more reader attention than any reports on the Impeachment trial of the President or even the tribulations of the Duke and Duchess of Sussex.
** An entire section of the paper '''"One Nation, Tracked"''' describing '''"The Smartphone Data Collection Industry"''' showed conclusively that we cannot trust the phone apps that brought us to this point.
* The Monday 2020-03-09 release of [https://www.healthit.gov/curesrule/ ONC’s Cures Act Final Rule] which supports seamless and secure access, exchange, and use of electronic health information
* And the Tuesday 2020-03-10 report in the New York Times [https://www.nytimes.com/2020/03/09/business/medical-app-patients-data-privacy.html New Data Rules Could Empower Patients but Undermine Their Privacy] Which points out that forcing adoption without concern for patient privacy would harm patients rights.
* This pattern is a sub-set of the [[User Choice Pattern]] which covers the general user choice issues. It contains the general context and should be read in conjunction with this page.
* This document assumes that the *[https://www.healthit.gov/sites/default/files/page/2019-04/FINALTEFCAQTF41719508version.pdf Trusted Exchange Framework and Common Agreement (TEFCA) Draft 2] (2019-04-19) will apply. From that it assumes that some means must be found for level 2 authentication of patients that will not be faced with the same rejection as was evidenced in earlier attempts at TLS client authentication.
* Patient choice is acclaimed by existing health care solutions, often as a means for the providers to avoid the responsibility for making good, but tough, clinical and security decisions which might possibly result in bad outcomes and liability to large tort actions. If the blame can be placed on the patient, the care provider might avoid lawsuits.
* For a long time, '''actual''' patient choice has been ignored. Now that more enterprises have found that patients will not use products that they don't like or don't trust, every enterprise is claiming that their applications preserve patient choice. The reality does not quite live up to their claims.
* To understand what applications will satisfy patients, we cannot rely on enterprises that peddle solutions, we need to give the patients information about their choices and only then ask the patients what is really important to them.

The term "enterprise" is used on this page to include all purveyors of health care solutions from governments and non-profits to profit making companies.

==Problems==
* Patients have uniformly expressed a desire to control what and where they share their [https://tcwiki.azurewebsites.net/index.php?title=PHI Protected Health Information (PHI)].
* Patients also ask to have control of the applications that run on their smartphones particularly with respect to the way that they handle user private information and the way that they intrude on the attention of the user.
* If the patient chooses an application for their smartphone that downloads PHI, then that application has complete control over where that data goes.
* If the healthcare community decides to allow any smartphone application that the patient chooses to install on the smartphone, then the patient is at risk to loose control of their PHI.
* If the patient chooses to upload their PHI to just any website without knowledge of that sites' controls, then the patient is at risk to loose control of their PHI.
* The patient must be given the tools to assure that their PHI remains under their control. The healthcare community will loose the patient's trust if they don't enforce that.
* Without some other trust mark on the app, it is very difficult for the patient to determine if the app is covered by HIPAA. "If you see the term 'we are HIPAA-compliant', the basic rule of thumb is the program does not fall under HIPAA" from Pam Dixon, executive director of the World Privacy Forum as quoted by Thorin Klosowski in "Consider the Consequences of Trading Your Health Data. (2020-02-03) New York Times p. B7.
* The biggest problem for the covered HIPAA entity is what level of assurance of patient intent do they require to:
# Release data to the user, especially in machine readable form.
# Accept data input from the user to be added to the patient's permanent EHR.
# Accept medical directives from the patient, especially POLST directives.
* As a recipient of HIPAA covered data, any patient-centric health care app MUST take responsibility for protecting the data.
* Electronic Health Record sites must assure that any patient app accepts this responsibility before sending them PHI.
* All computer application software that is running on internet connected computers is subject to a daily barrage of attacks trying to exploit vulnerabilities in that software or the gullibility of the people operating those computers. The [https://www.healthcareitnews.com/news/8-out-10-mobile-health-apps-open-hipaa-violations-hacking-data-theft Healthcare IT News reported] that: "8 out of 10 mobile health apps open to HIPAA violations, hacking, data theft. Though the majority of executives surveyed by Arxan said they believe their apps are secure."
* A [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6371412/ recent evaluation of the security of health apps on smartphones] revealed the following: "We identified 116 eligible mobile phone apps. Of those, 4% (5/116) received a transparency score of acceptable, 28% (32/116) questionable, and 68% (79/116) unacceptable. Only a minority of the apps (49%) had a privacy policy." Clearly leaving security up to app developers without verification is not working today.
* In the US on 2020-02-20 data sharing is not based on FHIR standards but an older document exchange protocol that has little control and operates with no transparency to the patient. This Reddit post shows [https://www.reddit.com/r/privacy/comments/f5j7ad/your_doctors_are_sharing_your_private_health/ Your doctors are sharing your private health information to the state and feds (and it's not a HIPPA violation!)]
* Also a threat is [https://medcitynews.com/2021/04/some-proposed-hipaa-changes-could-inadvertently-expose-the-data-its-supposed-to-protect/?rf=1 Some proposed HIPAA changes could inadvertently expose the data it’s supposed to protect]. <blockquote>One of the changes involves allowing patients to receive their medical information via personal health applications — smartphone apps, for example — which are often developed and operated by third-party technology companies. But these companies are generally not governed by HIPAA, opening up patient health data to potential misuse. “The patient isn’t the only one getting the information in that situation, and so you wind up exposing information to tech platforms, app developers and others. That exposed information can then be shared with data brokers who create profiles on individuals, which can be used for potentially nefarious purposes. For example, it creates a gating opportunity where some people may get certain opportunities based on those profiles, and others are barred from those same opportunities. That’s according to Laura Hoffman, assistant director of federal affairs at the American Medical Association,</blockquote>
* Part of the problem is that sometimes the health services themselves pass patient records to app developers. For example the article [https://techcrunch.com/2021/09/30/uk-class-action-style-suit-filed-over-deepmind-nhs-health-data-scandal/ UK class action-style suit filed over DeepMind NHS health data scandal] describes live patient information passed from the UK NHS to a small developer and Google Deep Mind for development purposes. (2021-09-30)

==Solutions==
The patient is not accustomed to having a choice in their health as the insurance market has dictated that for decades. There are two obstacles to overcome to provide real choice to any consumer.
# The patient must learn that they have a choice. Even though the 21st Century Cares Act gives them choice, it is not enforceable until October 2020 since extended to October 2021..
# The patient must have easy access to clear data to make a choice. In particular the effectiveness and out-of-pocket cost of any procedure or medicine. This will probably be decided in a hit-or-miss approach unless some real user research can be done.
* The computer industry has learned that security cannot be a choice and has taken the responsibility to assure that their software does not expose the user to exploits that are launched regularly from any site that has access to the internet.
* If the patient is to have a choice about the release of their protected health information (PHI), they must be able to rely on the software that is installed on the healthcare providers computers as well as any software that they use on their own computers.
* To enable real patient choice, the healthcare community must create a trust registry of web sites and applications that are to be trusted with patient healthcare information (covered HIPAA entities). In other words, enabling patient choice on access to their data, the patient must be limited to the use of secure sites and applications that can be trusted to maintain the security of that information.
* The healthcare community must prevent any sites or apps that are not in the US Healthcare Assurance Registry from downloading patient data.
* The healthcare community should prevent any user app from uploading data is not from a trusted site or app into the patient's EHR.
*To be sure that patient concerns are met, a [[Trustworthy Healthcare Ecosystem]] must exist to be able to strongly identify these actors:
# The Patient must be able to prove that they are the owner (or [[Guardian]] of the owner) of the PHI.
# The Patient app must be trusted to faithfully present the patient authentication and protect PHI that the patient downloads.
# The source of the data must be trusted to show the provenance of the data. That is to show that the data is legitimate and accurate.
# If the patient chooses to share PHI, they must be able to assure that the recipient of the data will treat the data with the full protections of HIPAA.
* The question about PHI that is released to non-HIPAA covered entities has not yet been addressed. But is it clear that the patient needs to understand the implications and risks of such a release before it happens.
===Expected Types of Access Methods===
For users with some computer literacy:
# Browser on a personal or public device
# User portable device with browser and local storage for continued connectivity.
# User agent running the cloud that can be accessed with any browser
# User agent in a native app on a user owned device using traditional sources of an identifier
# User agent in a native app on a portable user owned device with a self-issued identifier
===Consent and Notification===
# The current medical practice is for the user to be given a form at the physician’s office that give consent to keep records in a patient’s EHR is a health data repository (called a data controller in the GDPR) for the physician, the patient and other providers. This is typically extended to referrals where the patient is giving consent to send medical records that are relevant to the referral. No change is proposed here.
# Once the records are at the referred EHR, the Cares Act gives the patient the right to see and acquire PHI from that source as well. Clearly it is important for remote access by the user to exercise this right, but only under careful identity proofing with patient credentials which are protected to AAL2 in NIST 800-63-3B,
# Patient Consent that is provided on any such protected remote access must be recorded and acknowledged to the patient, preferable with a receipt that is similar in concept to the one that the patient receives in the office. (Also known as the Break-the-Glass scenario.)
# Users must be able to determine which information will be released to other locations which will be conditioned on the purpose of that access
# Users will always be notified of changes to access list, medicines and other issues related to their health and security breaches
# More information is included on the wiki page [[Patient Consent]].

===Other functionality that a device app could supply===
# The app could be used by a medical record source to determine which categories of medical records the patient wants to share with other HIPAA covered entities.
# The app could respond to requests by an EHR for current information, with the data is held by the user, or by forwarding the request to the source EHR.
# The patient or legal system can enable guardians to use the app for access or update of patient data.

==References==

* [https://www.ga4gh.org/wp-content/uploads/GA4GH-Final-Revised-Consent-Policy_16Sept2019.pdf Global Alliance for Genomics and Health: Consent Policy]

===Other Material===
The following use cases contain details about the location where a user agent maintains [[Patient Choice]] (ie on the user's phone or in the cloud) among other issues in a [[Trustworthy Healthcare Ecosystem]].
* The [[Remote Attestation Use Case]] wiki page describes a user with a Smartphone going through a series of actions that will provide subsequent statements from that user on that phone with a higher level of assurance.
* The [[User Agent in the Cloud]] wiki page describes a user with a modern browser on a internet connected computing device establishing an agent on a trustworthy website to allow access to information on their behalf.
These patient choices and their attendant liability are addressed in Design Principles/Goals for a Healthcare Identity Environment Architecture above, a current copy will be maintained on the [https://kantarainitiative.org/confluence/display/healthidassurance/Identity+Assurance+Principles Kantara website].

[[Category:Profile]]
[[Category:Privacy]]
[[Category:Use Cases]]
[[Category:Health]]

Patient Choice

2021-10-01T01:41:06Z

Tomjones: /* Problems */

==Full Title==
The options that a patient should have in accessing and sharing their [https://tcwiki.azurewebsites.net/index.php?title=PHI Protected Health Information (PHI)] with trusted medical providers.
===Source===
The Federated Identifiers for Resilient Ecosystems Work Group of the Kantara Initiative.
=== Last updated===
2021-04-30 (HIPAA changes can introduce new threats)

==Context==
* For more context see the wiki page [[Native Apps for US Healthcare]] which looks at the apps that control access to user secrets in hardware. This page considers web apps as well.
* The major context for this page is an environment where user's private data is treated like a commodity to be bought and sold. These two postings in the Sunday New York Times on 2020-01-26 demonstrate conclusively that a [[Trustworthy Healthcare Ecosystem]] requires more attention to the handling of healthcare data that is common at this time:
** The report on '''The Secretive Company That Might End Privacy as we Know it''' received more reader attention than any reports on the Impeachment trial of the President or even the tribulations of the Duke and Duchess of Sussex.
** An entire section of the paper '''"One Nation, Tracked"''' describing '''"The Smartphone Data Collection Industry"''' showed conclusively that we cannot trust the phone apps that brought us to this point.
* The Monday 2020-03-09 release of [https://www.healthit.gov/curesrule/ ONC’s Cures Act Final Rule] which supports seamless and secure access, exchange, and use of electronic health information
* And the Tuesday 2020-03-10 report in the New York Times [https://www.nytimes.com/2020/03/09/business/medical-app-patients-data-privacy.html New Data Rules Could Empower Patients but Undermine Their Privacy] Which points out that forcing adoption without concern for patient privacy would harm patients rights.
* This pattern is a sub-set of the [[User Choice Pattern]] which covers the general user choice issues. It contains the general context and should be read in conjunction with this page.
* This document assumes that the *[https://www.healthit.gov/sites/default/files/page/2019-04/FINALTEFCAQTF41719508version.pdf Trusted Exchange Framework and Common Agreement (TEFCA) Draft 2] (2019-04-19) will apply. From that it assumes that some means must be found for level 2 authentication of patients that will not be faced with the same rejection as was evidenced in earlier attempts at TLS client authentication.
* Patient choice is acclaimed by existing health care solutions, often as a means for the providers to avoid the responsibility for making good, but tough, clinical and security decisions which might possibly result in bad outcomes and liability to large tort actions. If the blame can be placed on the patient, the care provider might avoid lawsuits.
* For a long time, '''actual''' patient choice has been ignored. Now that more enterprises have found that patients will not use products that they don't like or don't trust, every enterprise is claiming that their applications preserve patient choice. The reality does not quite live up to their claims.
* To understand what applications will satisfy patients, we cannot rely on enterprises that peddle solutions, we need to give the patients information about their choices and only then ask the patients what is really important to them.

The term "enterprise" is used on this page to include all purveyors of health care solutions from governments and non-profits to profit making companies.

==Problems==
* Patients have uniformly expressed a desire to control what and where they share their [https://tcwiki.azurewebsites.net/index.php?title=PHI Protected Health Information (PHI)].
* Patients also ask to have control of the applications that run on their smartphones particularly with respect to the way that they handle user private information and the way that they intrude on the attention of the user.
* If the patient chooses an application for their smartphone that downloads PHI, then that application has complete control over where that data goes.
* If the healthcare community decides to allow any smartphone application that the patient chooses to install on the smartphone, then the patient is at risk to loose control of their PHI.
* If the patient chooses to upload their PHI to just any website without knowledge of that sites' controls, then the patient is at risk to loose control of their PHI.
* The patient must be given the tools to assure that their PHI remains under their control. The healthcare community will loose the patient's trust if they don't enforce that.
* Without some other trust mark on the app, it is very difficult for the patient to determine if the app is covered by HIPAA. "If you see the term 'we are HIPAA-compliant', the basic rule of thumb is the program does not fall under HIPAA" from Pam Dixon, executive director of the World Privacy Forum as quoted by Thorin Klosowski in "Consider the Consequences of Trading Your Health Data. (2020-02-03) New York Times p. B7.
* The biggest problem for the covered HIPAA entity is what level of assurance of patient intent do they require to:
# Release data to the user, especially in machine readable form.
# Accept data input from the user to be added to the patient's permanent EHR.
# Accept medical directives from the patient, especially POLST directives.
* As a recipient of HIPAA covered data, any patient-centric health care app MUST take responsibility for protecting the data.
* Electronic Health Record sites must assure that any patient app accepts this responsibility before sending them PHI.
* All computer application software that is running on internet connected computers is subject to a daily barrage of attacks trying to exploit vulnerabilities in that software or the gullibility of the people operating those computers. The [https://www.healthcareitnews.com/news/8-out-10-mobile-health-apps-open-hipaa-violations-hacking-data-theft Healthcare IT News reported] that: "8 out of 10 mobile health apps open to HIPAA violations, hacking, data theft. Though the majority of executives surveyed by Arxan said they believe their apps are secure."
* A [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6371412/ recent evaluation of the security of health apps on smartphones] revealed the following: "We identified 116 eligible mobile phone apps. Of those, 4% (5/116) received a transparency score of acceptable, 28% (32/116) questionable, and 68% (79/116) unacceptable. Only a minority of the apps (49%) had a privacy policy." Clearly leaving security up to app developers without verification is not working today.
* In the US on 2020-02-20 data sharing is not based on FHIR standards but an older document exchange protocol that has little control and operates with no transparency to the patient. This Reddit post shows [https://www.reddit.com/r/privacy/comments/f5j7ad/your_doctors_are_sharing_your_private_health/ Your doctors are sharing your private health information to the state and feds (and it's not a HIPPA violation!)]
* Also a threat is [https://medcitynews.com/2021/04/some-proposed-hipaa-changes-could-inadvertently-expose-the-data-its-supposed-to-protect/?rf=1 Some proposed HIPAA changes could inadvertently expose the data it’s supposed to protect]. <blockquote>One of the changes involves allowing patients to receive their medical information via personal health applications — smartphone apps, for example — which are often developed and operated by third-party technology companies. But these companies are generally not governed by HIPAA, opening up patient health data to potential misuse. “The patient isn’t the only one getting the information in that situation, and so you wind up exposing information to tech platforms, app developers and others. That exposed information can then be shared with data brokers who create profiles on individuals, which can be used for potentially nefarious purposes. For example, it creates a gating opportunity where some people may get certain opportunities based on those profiles, and others are barred from those same opportunities. That’s according to Laura Hoffman, assistant director of federal affairs at the American Medical Association,</blockquote>
* Part of the problem is that sometimes the health services themselves pass patient records to app developers. For example the article [https://techcrunch.com/2021/09/30/uk-class-action-style-suit-filed-over-deepmind-nhs-health-data-scandal/ UK class action-style suit filed over DeepMind NHS health data scandal] describes live patient information passed from the UK NHS to a small developer and Google Deep Mind for development purposes.

==Solutions==
The patient is not accustomed to having a choice in their health as the insurance market has dictated that for decades. There are two obstacles to overcome to provide real choice to any consumer.
# The patient must learn that they have a choice. Even though the 21st Century Cares Act gives them choice, it is not enforceable until October 2020 since extended to October 2021..
# The patient must have easy access to clear data to make a choice. In particular the effectiveness and out-of-pocket cost of any procedure or medicine. This will probably be decided in a hit-or-miss approach unless some real user research can be done.
* The computer industry has learned that security cannot be a choice and has taken the responsibility to assure that their software does not expose the user to exploits that are launched regularly from any site that has access to the internet.
* If the patient is to have a choice about the release of their protected health information (PHI), they must be able to rely on the software that is installed on the healthcare providers computers as well as any software that they use on their own computers.
* To enable real patient choice, the healthcare community must create a trust registry of web sites and applications that are to be trusted with patient healthcare information (covered HIPAA entities). In other words, enabling patient choice on access to their data, the patient must be limited to the use of secure sites and applications that can be trusted to maintain the security of that information.
* The healthcare community must prevent any sites or apps that are not in the US Healthcare Assurance Registry from downloading patient data.
* The healthcare community should prevent any user app from uploading data is not from a trusted site or app into the patient's EHR.
*To be sure that patient concerns are met, a [[Trustworthy Healthcare Ecosystem]] must exist to be able to strongly identify these actors:
# The Patient must be able to prove that they are the owner (or [[Guardian]] of the owner) of the PHI.
# The Patient app must be trusted to faithfully present the patient authentication and protect PHI that the patient downloads.
# The source of the data must be trusted to show the provenance of the data. That is to show that the data is legitimate and accurate.
# If the patient chooses to share PHI, they must be able to assure that the recipient of the data will treat the data with the full protections of HIPAA.
* The question about PHI that is released to non-HIPAA covered entities has not yet been addressed. But is it clear that the patient needs to understand the implications and risks of such a release before it happens.
===Expected Types of Access Methods===
For users with some computer literacy:
# Browser on a personal or public device
# User portable device with browser and local storage for continued connectivity.
# User agent running the cloud that can be accessed with any browser
# User agent in a native app on a user owned device using traditional sources of an identifier
# User agent in a native app on a portable user owned device with a self-issued identifier
===Consent and Notification===
# The current medical practice is for the user to be given a form at the physician’s office that give consent to keep records in a patient’s EHR is a health data repository (called a data controller in the GDPR) for the physician, the patient and other providers. This is typically extended to referrals where the patient is giving consent to send medical records that are relevant to the referral. No change is proposed here.
# Once the records are at the referred EHR, the Cares Act gives the patient the right to see and acquire PHI from that source as well. Clearly it is important for remote access by the user to exercise this right, but only under careful identity proofing with patient credentials which are protected to AAL2 in NIST 800-63-3B,
# Patient Consent that is provided on any such protected remote access must be recorded and acknowledged to the patient, preferable with a receipt that is similar in concept to the one that the patient receives in the office. (Also known as the Break-the-Glass scenario.)
# Users must be able to determine which information will be released to other locations which will be conditioned on the purpose of that access
# Users will always be notified of changes to access list, medicines and other issues related to their health and security breaches
# More information is included on the wiki page [[Patient Consent]].

===Other functionality that a device app could supply===
# The app could be used by a medical record source to determine which categories of medical records the patient wants to share with other HIPAA covered entities.
# The app could respond to requests by an EHR for current information, with the data is held by the user, or by forwarding the request to the source EHR.
# The patient or legal system can enable guardians to use the app for access or update of patient data.

==References==

* [https://www.ga4gh.org/wp-content/uploads/GA4GH-Final-Revised-Consent-Policy_16Sept2019.pdf Global Alliance for Genomics and Health: Consent Policy]

===Other Material===
The following use cases contain details about the location where a user agent maintains [[Patient Choice]] (ie on the user's phone or in the cloud) among other issues in a [[Trustworthy Healthcare Ecosystem]].
* The [[Remote Attestation Use Case]] wiki page describes a user with a Smartphone going through a series of actions that will provide subsequent statements from that user on that phone with a higher level of assurance.
* The [[User Agent in the Cloud]] wiki page describes a user with a modern browser on a internet connected computing device establishing an agent on a trustworthy website to allow access to information on their behalf.
These patient choices and their attendant liability are addressed in Design Principles/Goals for a Healthcare Identity Environment Architecture above, a current copy will be maintained on the [https://kantarainitiative.org/confluence/display/healthidassurance/Identity+Assurance+Principles Kantara website].

[[Category:Profile]]
[[Category:Privacy]]
[[Category:Use Cases]]
[[Category:Health]]

Patient Choice

2021-09-30T00:54:05Z

Tomjones: /* Last updated */

==Full Title==
The options that a patient should have in accessing and sharing their [https://tcwiki.azurewebsites.net/index.php?title=PHI Protected Health Information (PHI)] with trusted medical providers.
===Source===
The Federated Identifiers for Resilient Ecosystems Work Group of the Kantara Initiative.
=== Last updated===
2021-04-30 (HIPAA changes can introduce new threats)

==Context==
* For more context see the wiki page [[Native Apps for US Healthcare]] which looks at the apps that control access to user secrets in hardware. This page considers web apps as well.
* The major context for this page is an environment where user's private data is treated like a commodity to be bought and sold. These two postings in the Sunday New York Times on 2020-01-26 demonstrate conclusively that a [[Trustworthy Healthcare Ecosystem]] requires more attention to the handling of healthcare data that is common at this time:
** The report on '''The Secretive Company That Might End Privacy as we Know it''' received more reader attention than any reports on the Impeachment trial of the President or even the tribulations of the Duke and Duchess of Sussex.
** An entire section of the paper '''"One Nation, Tracked"''' describing '''"The Smartphone Data Collection Industry"''' showed conclusively that we cannot trust the phone apps that brought us to this point.
* The Monday 2020-03-09 release of [https://www.healthit.gov/curesrule/ ONC’s Cures Act Final Rule] which supports seamless and secure access, exchange, and use of electronic health information
* And the Tuesday 2020-03-10 report in the New York Times [https://www.nytimes.com/2020/03/09/business/medical-app-patients-data-privacy.html New Data Rules Could Empower Patients but Undermine Their Privacy] Which points out that forcing adoption without concern for patient privacy would harm patients rights.
* This pattern is a sub-set of the [[User Choice Pattern]] which covers the general user choice issues. It contains the general context and should be read in conjunction with this page.
* This document assumes that the *[https://www.healthit.gov/sites/default/files/page/2019-04/FINALTEFCAQTF41719508version.pdf Trusted Exchange Framework and Common Agreement (TEFCA) Draft 2] (2019-04-19) will apply. From that it assumes that some means must be found for level 2 authentication of patients that will not be faced with the same rejection as was evidenced in earlier attempts at TLS client authentication.
* Patient choice is acclaimed by existing health care solutions, often as a means for the providers to avoid the responsibility for making good, but tough, clinical and security decisions which might possibly result in bad outcomes and liability to large tort actions. If the blame can be placed on the patient, the care provider might avoid lawsuits.
* For a long time, '''actual''' patient choice has been ignored. Now that more enterprises have found that patients will not use products that they don't like or don't trust, every enterprise is claiming that their applications preserve patient choice. The reality does not quite live up to their claims.
* To understand what applications will satisfy patients, we cannot rely on enterprises that peddle solutions, we need to give the patients information about their choices and only then ask the patients what is really important to them.

The term "enterprise" is used on this page to include all purveyors of health care solutions from governments and non-profits to profit making companies.

==Problems==
* Patients have uniformly expressed a desire to control what and where they share their [https://tcwiki.azurewebsites.net/index.php?title=PHI Protected Health Information (PHI)].
* Patients also ask to have control of the applications that run on their smartphones particularly with respect to the way that they handle user private information and the way that they intrude on the attention of the user.
* If the patient chooses an application for their smartphone that downloads PHI, then that application has complete control over where that data goes.
* If the healthcare community decides to allow any smartphone application that the patient chooses to install on the smartphone, then the patient is at risk to loose control of their PHI.
* If the patient chooses to upload their PHI to just any website without knowledge of that sites' controls, then the patient is at risk to loose control of their PHI.
* The patient must be given the tools to assure that their PHI remains under their control. The healthcare community will loose the patient's trust if they don't enforce that.
* Without some other trust mark on the app, it is very difficult for the patient to determine if the app is covered by HIPAA. "If you see the term 'we are HIPAA-compliant', the basic rule of thumb is the program does not fall under HIPAA" from Pam Dixon, executive director of the World Privacy Forum as quoted by Thorin Klosowski in "Consider the Consequences of Trading Your Health Data. (2020-02-03) New York Times p. B7.
* The biggest problem for the covered HIPAA entity is what level of assurance of patient intent do they require to:
# Release data to the user, especially in machine readable form.
# Accept data input from the user to be added to the patient's permanent EHR.
# Accept medical directives from the patient, especially POLST directives.
* As a recipient of HIPAA covered data, any patient-centric health care app MUST take responsibility for protecting the data.
* Electronic Health Record sites must assure that any patient app accepts this responsibility before sending them PHI.
* All computer application software that is running on internet connected computers is subject to a daily barrage of attacks trying to exploit vulnerabilities in that software or the gullibility of the people operating those computers. The [https://www.healthcareitnews.com/news/8-out-10-mobile-health-apps-open-hipaa-violations-hacking-data-theft Healthcare IT News reported] that: "8 out of 10 mobile health apps open to HIPAA violations, hacking, data theft. Though the majority of executives surveyed by Arxan said they believe their apps are secure."
* A [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6371412/ recent evaluation of the security of health apps on smartphones] revealed the following: "We identified 116 eligible mobile phone apps. Of those, 4% (5/116) received a transparency score of acceptable, 28% (32/116) questionable, and 68% (79/116) unacceptable. Only a minority of the apps (49%) had a privacy policy." Clearly leaving security up to app developers without verification is not working today.
* In the US on 2020-02-20 data sharing is not based on FHIR standards but an older document exchange protocol that has little control and operates with no transparency to the patient. This Reddit post shows [https://www.reddit.com/r/privacy/comments/f5j7ad/your_doctors_are_sharing_your_private_health/ Your doctors are sharing your private health information to the state and feds (and it's not a HIPPA violation!)]
* Also a threat is [https://medcitynews.com/2021/04/some-proposed-hipaa-changes-could-inadvertently-expose-the-data-its-supposed-to-protect/?rf=1 Some proposed HIPAA changes could inadvertently expose the data it’s supposed to protect]. <blockquote>One of the changes involves allowing patients to receive their medical information via personal health applications — smartphone apps, for example — which are often developed and operated by third-party technology companies. But these companies are generally not governed by HIPAA, opening up patient health data to potential misuse. “The patient isn’t the only one getting the information in that situation, and so you wind up exposing information to tech platforms, app developers and others. That exposed information can then be shared with data brokers who create profiles on individuals, which can be used for potentially nefarious purposes. For example, it creates a gating opportunity where some people may get certain opportunities based on those profiles, and others are barred from those same opportunities. That’s according to Laura Hoffman, assistant director of federal affairs at the American Medical Association,</blockquote>

==Solutions==
The patient is not accustomed to having a choice in their health as the insurance market has dictated that for decades. There are two obstacles to overcome to provide real choice to any consumer.
# The patient must learn that they have a choice. Even though the 21st Century Cares Act gives them choice, it is not enforceable until October 2020 since extended to October 2021..
# The patient must have easy access to clear data to make a choice. In particular the effectiveness and out-of-pocket cost of any procedure or medicine. This will probably be decided in a hit-or-miss approach unless some real user research can be done.
* The computer industry has learned that security cannot be a choice and has taken the responsibility to assure that their software does not expose the user to exploits that are launched regularly from any site that has access to the internet.
* If the patient is to have a choice about the release of their protected health information (PHI), they must be able to rely on the software that is installed on the healthcare providers computers as well as any software that they use on their own computers.
* To enable real patient choice, the healthcare community must create a trust registry of web sites and applications that are to be trusted with patient healthcare information (covered HIPAA entities). In other words, enabling patient choice on access to their data, the patient must be limited to the use of secure sites and applications that can be trusted to maintain the security of that information.
* The healthcare community must prevent any sites or apps that are not in the US Healthcare Assurance Registry from downloading patient data.
* The healthcare community should prevent any user app from uploading data is not from a trusted site or app into the patient's EHR.
*To be sure that patient concerns are met, a [[Trustworthy Healthcare Ecosystem]] must exist to be able to strongly identify these actors:
# The Patient must be able to prove that they are the owner (or [[Guardian]] of the owner) of the PHI.
# The Patient app must be trusted to faithfully present the patient authentication and protect PHI that the patient downloads.
# The source of the data must be trusted to show the provenance of the data. That is to show that the data is legitimate and accurate.
# If the patient chooses to share PHI, they must be able to assure that the recipient of the data will treat the data with the full protections of HIPAA.
* The question about PHI that is released to non-HIPAA covered entities has not yet been addressed. But is it clear that the patient needs to understand the implications and risks of such a release before it happens.
===Expected Types of Access Methods===
For users with some computer literacy:
# Browser on a personal or public device
# User portable device with browser and local storage for continued connectivity.
# User agent running the cloud that can be accessed with any browser
# User agent in a native app on a user owned device using traditional sources of an identifier
# User agent in a native app on a portable user owned device with a self-issued identifier
===Consent and Notification===
# The current medical practice is for the user to be given a form at the physician’s office that give consent to keep records in a patient’s EHR is a health data repository (called a data controller in the GDPR) for the physician, the patient and other providers. This is typically extended to referrals where the patient is giving consent to send medical records that are relevant to the referral. No change is proposed here.
# Once the records are at the referred EHR, the Cares Act gives the patient the right to see and acquire PHI from that source as well. Clearly it is important for remote access by the user to exercise this right, but only under careful identity proofing with patient credentials which are protected to AAL2 in NIST 800-63-3B,
# Patient Consent that is provided on any such protected remote access must be recorded and acknowledged to the patient, preferable with a receipt that is similar in concept to the one that the patient receives in the office. (Also known as the Break-the-Glass scenario.)
# Users must be able to determine which information will be released to other locations which will be conditioned on the purpose of that access
# Users will always be notified of changes to access list, medicines and other issues related to their health and security breaches
# More information is included on the wiki page [[Patient Consent]].

===Other functionality that a device app could supply===
# The app could be used by a medical record source to determine which categories of medical records the patient wants to share with other HIPAA covered entities.
# The app could respond to requests by an EHR for current information, with the data is held by the user, or by forwarding the request to the source EHR.
# The patient or legal system can enable guardians to use the app for access or update of patient data.

==References==

* [https://www.ga4gh.org/wp-content/uploads/GA4GH-Final-Revised-Consent-Policy_16Sept2019.pdf Global Alliance for Genomics and Health: Consent Policy]

===Other Material===
The following use cases contain details about the location where a user agent maintains [[Patient Choice]] (ie on the user's phone or in the cloud) among other issues in a [[Trustworthy Healthcare Ecosystem]].
* The [[Remote Attestation Use Case]] wiki page describes a user with a Smartphone going through a series of actions that will provide subsequent statements from that user on that phone with a higher level of assurance.
* The [[User Agent in the Cloud]] wiki page describes a user with a modern browser on a internet connected computing device establishing an agent on a trustworthy website to allow access to information on their behalf.
These patient choices and their attendant liability are addressed in Design Principles/Goals for a Healthcare Identity Environment Architecture above, a current copy will be maintained on the [https://kantarainitiative.org/confluence/display/healthidassurance/Identity+Assurance+Principles Kantara website].

[[Category:Profile]]
[[Category:Privacy]]
[[Category:Use Cases]]
[[Category:Health]]

User Engagement

2021-08-26T16:37:13Z

Tomjones: /* Soltuions */

==Full Title or Meme==
This topic takes the concept of [[User Experience]] as a deep interaction with the user over time. The intent is to help Kantara plan for the next phases 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 of an additional specification to the current set of specifications 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.

===Actors===
These apply to the entities that appear on the the digital web and not any real-world interactions.
* User
* User Delegate
* Technology vendor - provider (eg EHR)
* Technology vendor - user (eg Phone App)
* Primary Provider (original RP accessed by the user)
* Other Providers (Other web sites that were not on the user's original agenda)

The objective is to focus the discussion between the user and the site that the user wants to access.

==Proofs==
===Context===
is a statement of the set of rules that apply to the current interchanges. (eg US Healthcare HIPAA, aka federation)

===User Authentication===
is the traditional role for an Identifier provider (IdP). In some ways it becomes an anachronism as we disassemble, enhance and reassemble the parts below into a complete [[User Engagement]].

===Identity Proofing===
is the process of binding an identifier to a real-world person. At its core [[Identity Proofing]] is just a comparison of biometric factors of the real-world person to some subset of the user credentials that are accumulated over a user's life-time.

===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.
===Notice and Consent===
* How is the patient informed of the transfer of information between providers with a frequency and level of detail that understands the user's expectations.
* Notice can be contemporaneous with the interaction, or can occur later if an event occurs at the RP or in a receipt of some sort that the user can view if questions about the interaction arise later.

==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 attacker 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 use of only 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.

==Solutions==
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.
# User Managed Access (UMA)
# Consent Receipt (now the advanced notice and consumer receipt)
# Mobile Authentication Assurance Statement. (MAAS)
# [https://docs.kantarainitiative.org/PImDL-V1-Final.html 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 considered 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.
# The consent receipt is being expanded into
## a consent record.
## a generalized notification.
# The MAAS is being bound, in-real-time, into:
## proof that the user is present at the device
## proof that the software running on the device is same code that received the MAAS
## current device configuration that describes security settings (not user settings.)

==References==

===Research===
* [https://asistdl.onlinelibrary.wiley.com/doi/abs/10.1002/asi.20801 What is user engagement? A conceptual framework for defining user engagement with technology] <blockquote>The purpose of this article is to critically deconstruct the term engagement as it applies to peoples' experiences with technology. Through an extensive, critical multidisciplinary literature review and exploratory study of users of Web searching, online shopping, Webcasting, and gaming applications, we conceptually and operationally defined engagement. Building on past research, we conducted semistructured interviews with the users of four applications to explore their perception of being engaged with the technology. Results indicate that engagement is a process comprised of four distinct stages: point of engagement, period of sustained engagement, disengagement, and reengagement. Furthermore, the process is characterized by attributes of engagement that pertain to the user, the system, and user-system interaction. We also found evidence of the factors that contribute to nonengagement. Emerging from this research is a definition of engagement—a term not defined consistently in past work—as a quality of user experience characterized by attributes of challenge, positive affect, endurability, aesthetic and sensory appeal, attention, feedback, variety/novelty, interactivity, and perceived user control. This exploratory work provides the foundation for future work to test the conceptual model in various application areas, and to develop methods to measure engaging user experiences.</blockquote>

[[Category: User Experience]]
[[Category: Trust]]

User Engagement

2021-08-26T16:35:31Z

Tomjones: /* Context */

==Full Title or Meme==
This topic takes the concept of [[User Experience]] as a deep interaction with the user over time. The intent is to help Kantara plan for the next phases 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 of an additional specification to the current set of specifications 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.

===Actors===
These apply to the entities that appear on the the digital web and not any real-world interactions.
* User
* User Delegate
* Technology vendor - provider (eg EHR)
* Technology vendor - user (eg Phone App)
* Primary Provider (original RP accessed by the user)
* Other Providers (Other web sites that were not on the user's original agenda)

The objective is to focus the discussion between the user and the site that the user wants to access.

==Proofs==
===Context===
is a statement of the set of rules that apply to the current interchanges. (eg US Healthcare HIPAA, aka federation)

===User Authentication===
is the traditional role for an Identifier provider (IdP). In some ways it becomes an anachronism as we disassemble, enhance and reassemble the parts below into a complete [[User Engagement]].

===Identity Proofing===
is the process of binding an identifier to a real-world person. At its core [[Identity Proofing]] is just a comparison of biometric factors of the real-world person to some subset of the user credentials that are accumulated over a user's life-time.

===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.
===Notice and Consent===
* How is the patient informed of the transfer of information between providers with a frequency and level of detail that understands the user's expectations.
* Notice can be contemporaneous with the interaction, or can occur later if an event occurs at the RP or in a receipt of some sort that the user can view if questions about the interaction arise later.

==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 attacker 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 use of only 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.
# User Managed Access
# Consent Receipt
# Mobile Authentication Assurance Statement.
# [https://docs.kantarainitiative.org/PImDL-V1-Final.html 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 considered 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.
# The consent receipt is being expanded into
## a consent record.
## a generalized notification.
# The MAAS is being bound, in-real-time, into:
## proof that the user is present at the device
## proof that the software running on the device is same code that received the MAAS
## current device configuration that describes security settings (not user settings.)

==References==

===Research===
* [https://asistdl.onlinelibrary.wiley.com/doi/abs/10.1002/asi.20801 What is user engagement? A conceptual framework for defining user engagement with technology] <blockquote>The purpose of this article is to critically deconstruct the term engagement as it applies to peoples' experiences with technology. Through an extensive, critical multidisciplinary literature review and exploratory study of users of Web searching, online shopping, Webcasting, and gaming applications, we conceptually and operationally defined engagement. Building on past research, we conducted semistructured interviews with the users of four applications to explore their perception of being engaged with the technology. Results indicate that engagement is a process comprised of four distinct stages: point of engagement, period of sustained engagement, disengagement, and reengagement. Furthermore, the process is characterized by attributes of engagement that pertain to the user, the system, and user-system interaction. We also found evidence of the factors that contribute to nonengagement. Emerging from this research is a definition of engagement—a term not defined consistently in past work—as a quality of user experience characterized by attributes of challenge, positive affect, endurability, aesthetic and sensory appeal, attention, feedback, variety/novelty, interactivity, and perceived user control. This exploratory work provides the foundation for future work to test the conceptual model in various application areas, and to develop methods to measure engaging user experiences.</blockquote>

[[Category: User Experience]]
[[Category: Trust]]

User Engagement

2021-08-26T16:34:47Z

Tomjones: /* Context */

==Full Title or Meme==
This topic takes the concept of [[User Experience]] as a deep interaction with the user over time. The intent is to help Kantara plan for the next phases 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 of a 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.

===Actors===
These apply to the entities that appear on the the digital web and not any real-world interactions.
* User
* User Delegate
* Technology vendor - provider (eg EHR)
* Technology vendor - user (eg Phone App)
* Primary Provider (original RP accessed by the user)
* Other Providers (Other web sites that were not on the user's original agenda)

The objective is to focus the discussion between the user and the site that the user wants to access.

==Proofs==
===Context===
is a statement of the set of rules that apply to the current interchanges. (eg US Healthcare HIPAA, aka federation)

===User Authentication===
is the traditional role for an Identifier provider (IdP). In some ways it becomes an anachronism as we disassemble, enhance and reassemble the parts below into a complete [[User Engagement]].

===Identity Proofing===
is the process of binding an identifier to a real-world person. At its core [[Identity Proofing]] is just a comparison of biometric factors of the real-world person to some subset of the user credentials that are accumulated over a user's life-time.

===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.
===Notice and Consent===
* How is the patient informed of the transfer of information between providers with a frequency and level of detail that understands the user's expectations.
* Notice can be contemporaneous with the interaction, or can occur later if an event occurs at the RP or in a receipt of some sort that the user can view if questions about the interaction arise later.

==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 attacker 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 use of only 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.
# User Managed Access
# Consent Receipt
# Mobile Authentication Assurance Statement.
# [https://docs.kantarainitiative.org/PImDL-V1-Final.html 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 considered 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.
# The consent receipt is being expanded into
## a consent record.
## a generalized notification.
# The MAAS is being bound, in-real-time, into:
## proof that the user is present at the device
## proof that the software running on the device is same code that received the MAAS
## current device configuration that describes security settings (not user settings.)

==References==

===Research===
* [https://asistdl.onlinelibrary.wiley.com/doi/abs/10.1002/asi.20801 What is user engagement? A conceptual framework for defining user engagement with technology] <blockquote>The purpose of this article is to critically deconstruct the term engagement as it applies to peoples' experiences with technology. Through an extensive, critical multidisciplinary literature review and exploratory study of users of Web searching, online shopping, Webcasting, and gaming applications, we conceptually and operationally defined engagement. Building on past research, we conducted semistructured interviews with the users of four applications to explore their perception of being engaged with the technology. Results indicate that engagement is a process comprised of four distinct stages: point of engagement, period of sustained engagement, disengagement, and reengagement. Furthermore, the process is characterized by attributes of engagement that pertain to the user, the system, and user-system interaction. We also found evidence of the factors that contribute to nonengagement. Emerging from this research is a definition of engagement—a term not defined consistently in past work—as a quality of user experience characterized by attributes of challenge, positive affect, endurability, aesthetic and sensory appeal, attention, feedback, variety/novelty, interactivity, and perceived user control. This exploratory work provides the foundation for future work to test the conceptual model in various application areas, and to develop methods to measure engaging user experiences.</blockquote>

[[Category: User Experience]]
[[Category: Trust]]

User Engagement

2021-08-26T16:32:54Z

Tomjones: /* Actors */

==Full Title or Meme==
This topic takes the concept of [[User Experience]] as a deep interaction with the user over time. The intent is to help Kantara plan for the next phases 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.

===Actors===
These apply to the entities that appear on the the digital web and not any real-world interactions.
* User
* User Delegate
* Technology vendor - provider (eg EHR)
* Technology vendor - user (eg Phone App)
* Primary Provider (original RP accessed by the user)
* Other Providers (Other web sites that were not on the user's original agenda)

The objective is to focus the discussion between the user and the site that the user wants to access.

==Proofs==
===Context===
is a statement of the set of rules that apply to the current interchanges. (eg US Healthcare HIPAA, aka federation)

===User Authentication===
is the traditional role for an Identifier provider (IdP). In some ways it becomes an anachronism as we disassemble, enhance and reassemble the parts below into a complete [[User Engagement]].

===Identity Proofing===
is the process of binding an identifier to a real-world person. At its core [[Identity Proofing]] is just a comparison of biometric factors of the real-world person to some subset of the user credentials that are accumulated over a user's life-time.

===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.
===Notice and Consent===
* How is the patient informed of the transfer of information between providers with a frequency and level of detail that understands the user's expectations.
* Notice can be contemporaneous with the interaction, or can occur later if an event occurs at the RP or in a receipt of some sort that the user can view if questions about the interaction arise later.

==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 attacker 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 use of only 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.
# User Managed Access
# Consent Receipt
# Mobile Authentication Assurance Statement.
# [https://docs.kantarainitiative.org/PImDL-V1-Final.html 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 considered 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.
# The consent receipt is being expanded into
## a consent record.
## a generalized notification.
# The MAAS is being bound, in-real-time, into:
## proof that the user is present at the device
## proof that the software running on the device is same code that received the MAAS
## current device configuration that describes security settings (not user settings.)

==References==

===Research===
* [https://asistdl.onlinelibrary.wiley.com/doi/abs/10.1002/asi.20801 What is user engagement? A conceptual framework for defining user engagement with technology] <blockquote>The purpose of this article is to critically deconstruct the term engagement as it applies to peoples' experiences with technology. Through an extensive, critical multidisciplinary literature review and exploratory study of users of Web searching, online shopping, Webcasting, and gaming applications, we conceptually and operationally defined engagement. Building on past research, we conducted semistructured interviews with the users of four applications to explore their perception of being engaged with the technology. Results indicate that engagement is a process comprised of four distinct stages: point of engagement, period of sustained engagement, disengagement, and reengagement. Furthermore, the process is characterized by attributes of engagement that pertain to the user, the system, and user-system interaction. We also found evidence of the factors that contribute to nonengagement. Emerging from this research is a definition of engagement—a term not defined consistently in past work—as a quality of user experience characterized by attributes of challenge, positive affect, endurability, aesthetic and sensory appeal, attention, feedback, variety/novelty, interactivity, and perceived user control. This exploratory work provides the foundation for future work to test the conceptual model in various application areas, and to develop methods to measure engaging user experiences.</blockquote>

[[Category: User Experience]]
[[Category: Trust]]

User Engagement

2021-08-26T16:29:01Z

Tomjones: /* Actors */

==Full Title or Meme==
This topic takes the concept of [[User Experience]] as a deep interaction with the user over time. The intent is to help Kantara plan for the next phases 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.

===Actors===
These apply to the entities that appear on the the digital web.
* User
* User Delegate
* Technology vendor - provider (eg EHR)
* Technology vendor - user (eg Phone App)
* Primary Provider (original RP accessed by the user)
* Other Providers (Other web sites that were not on the user's original agenda)

The objective is to focus the discussion between the user and the site that the user wants to access.

==Proofs==
===Context===
is a statement of the set of rules that apply to the current interchanges. (eg US Healthcare HIPAA, aka federation)

===User Authentication===
is the traditional role for an Identifier provider (IdP). In some ways it becomes an anachronism as we disassemble, enhance and reassemble the parts below into a complete [[User Engagement]].

===Identity Proofing===
is the process of binding an identifier to a real-world person. At its core [[Identity Proofing]] is just a comparison of biometric factors of the real-world person to some subset of the user credentials that are accumulated over a user's life-time.

===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.
===Notice and Consent===
* How is the patient informed of the transfer of information between providers with a frequency and level of detail that understands the user's expectations.
* Notice can be contemporaneous with the interaction, or can occur later if an event occurs at the RP or in a receipt of some sort that the user can view if questions about the interaction arise later.

==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 attacker 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 use of only 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.
# User Managed Access
# Consent Receipt
# Mobile Authentication Assurance Statement.
# [https://docs.kantarainitiative.org/PImDL-V1-Final.html 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 considered 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.
# The consent receipt is being expanded into
## a consent record.
## a generalized notification.
# The MAAS is being bound, in-real-time, into:
## proof that the user is present at the device
## proof that the software running on the device is same code that received the MAAS
## current device configuration that describes security settings (not user settings.)

==References==

===Research===
* [https://asistdl.onlinelibrary.wiley.com/doi/abs/10.1002/asi.20801 What is user engagement? A conceptual framework for defining user engagement with technology] <blockquote>The purpose of this article is to critically deconstruct the term engagement as it applies to peoples' experiences with technology. Through an extensive, critical multidisciplinary literature review and exploratory study of users of Web searching, online shopping, Webcasting, and gaming applications, we conceptually and operationally defined engagement. Building on past research, we conducted semistructured interviews with the users of four applications to explore their perception of being engaged with the technology. Results indicate that engagement is a process comprised of four distinct stages: point of engagement, period of sustained engagement, disengagement, and reengagement. Furthermore, the process is characterized by attributes of engagement that pertain to the user, the system, and user-system interaction. We also found evidence of the factors that contribute to nonengagement. Emerging from this research is a definition of engagement—a term not defined consistently in past work—as a quality of user experience characterized by attributes of challenge, positive affect, endurability, aesthetic and sensory appeal, attention, feedback, variety/novelty, interactivity, and perceived user control. This exploratory work provides the foundation for future work to test the conceptual model in various application areas, and to develop methods to measure engaging user experiences.</blockquote>

[[Category: User Experience]]
[[Category: Trust]]

User Engagement

2021-08-17T21:51:34Z

Tomjones: /* Context */

==Full Title or Meme==
This topic takes the concept of [[User Experience]] as a deep interaction with the user over time. The intent is to help Kantara plan for the next phases 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.

===Actors===
* User
* User Delegate
* Technology vendor - provider (eg EHR)
* Technology vendor - user (eg Phone App)
* Primary Provider (original RP accessed by the user)
* Other Providers (Other web sites that were not on the user's original agenda)

The objective is to focus the discussion between the user and the site that the user wants to access.

==Proofs==
===Context===
is a statement of the set of rules that apply to the current interchanges. (eg US Healthcare HIPAA, aka federation)

===User Authentication===
is the traditional role for an Identifier provider (IdP). In some ways it becomes an anachronism as we disassemble, enhance and reassemble the parts below into a complete [[User Engagement]].

===Identity Proofing===
is the process of binding an identifier to a real-world person. At its core [[Identity Proofing]] is just a comparison of biometric factors of the real-world person to some subset of the user credentials that are accumulated over a user's life-time.

===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.
===Notice and Consent===
* How is the patient informed of the transfer of information between providers with a frequency and level of detail that understands the user's expectations.
* Notice can be contemporaneous with the interaction, or can occur later if an event occurs at the RP or in a receipt of some sort that the user can view if questions about the interaction arise later.

==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 attacker 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 use of only 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.
# User Managed Access
# Consent Receipt
# Mobile Authentication Assurance Statement.
# [https://docs.kantarainitiative.org/PImDL-V1-Final.html 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 considered 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.
# The consent receipt is being expanded into
## a consent record.
## a generalized notification.
# The MAAS is being bound, in-real-time, into:
## proof that the user is present at the device
## proof that the software running on the device is same code that received the MAAS
## current device configuration that describes security settings (not user settings.)

==References==

===Research===
* [https://asistdl.onlinelibrary.wiley.com/doi/abs/10.1002/asi.20801 What is user engagement? A conceptual framework for defining user engagement with technology] <blockquote>The purpose of this article is to critically deconstruct the term engagement as it applies to peoples' experiences with technology. Through an extensive, critical multidisciplinary literature review and exploratory study of users of Web searching, online shopping, Webcasting, and gaming applications, we conceptually and operationally defined engagement. Building on past research, we conducted semistructured interviews with the users of four applications to explore their perception of being engaged with the technology. Results indicate that engagement is a process comprised of four distinct stages: point of engagement, period of sustained engagement, disengagement, and reengagement. Furthermore, the process is characterized by attributes of engagement that pertain to the user, the system, and user-system interaction. We also found evidence of the factors that contribute to nonengagement. Emerging from this research is a definition of engagement—a term not defined consistently in past work—as a quality of user experience characterized by attributes of challenge, positive affect, endurability, aesthetic and sensory appeal, attention, feedback, variety/novelty, interactivity, and perceived user control. This exploratory work provides the foundation for future work to test the conceptual model in various application areas, and to develop methods to measure engaging user experiences.</blockquote>

[[Category: User Experience]]
[[Category: Trust]]

User Engagement

2021-08-17T21:50:55Z

Tomjones: /* Context */

==Full Title or Meme==
This topic takes the concept of [[User Experience]] as a deep interaction with the user over time. The intent is to help Kantara plan for the next phases 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.

===Actors===
* User
* User Delegate
* Technology vendor - provider (eg EHR)
* Technology vendor - user (eg Phone App)
* Primary Provider (original RP accessed by the user)
* Other Providers (Other web sites that were not on the user's original agenda)

The objective is to focus the discussion between the user and the site that the user wants to access.

==Proofs==
===Context===
is a statement of the set of rules that apply to the current interchanges. (eg US Healthcare HIPAA)

===User Authentication===
is the traditional role for an Identifier provider (IdP). In some ways it becomes an anachronism as we disassemble, enhance and reassemble the parts below into a complete [[User Engagement]].

===Identity Proofing===
is the process of binding an identifier to a real-world person. At its core [[Identity Proofing]] is just a comparison of biometric factors of the real-world person to some subset of the user credentials that are accumulated over a user's life-time.

===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.
===Notice and Consent===
* How is the patient informed of the transfer of information between providers with a frequency and level of detail that understands the user's expectations.
* Notice can be contemporaneous with the interaction, or can occur later if an event occurs at the RP or in a receipt of some sort that the user can view if questions about the interaction arise later.

==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 attacker 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 use of only 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.
# User Managed Access
# Consent Receipt
# Mobile Authentication Assurance Statement.
# [https://docs.kantarainitiative.org/PImDL-V1-Final.html 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 considered 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.
# The consent receipt is being expanded into
## a consent record.
## a generalized notification.
# The MAAS is being bound, in-real-time, into:
## proof that the user is present at the device
## proof that the software running on the device is same code that received the MAAS
## current device configuration that describes security settings (not user settings.)

==References==

===Research===
* [https://asistdl.onlinelibrary.wiley.com/doi/abs/10.1002/asi.20801 What is user engagement? A conceptual framework for defining user engagement with technology] <blockquote>The purpose of this article is to critically deconstruct the term engagement as it applies to peoples' experiences with technology. Through an extensive, critical multidisciplinary literature review and exploratory study of users of Web searching, online shopping, Webcasting, and gaming applications, we conceptually and operationally defined engagement. Building on past research, we conducted semistructured interviews with the users of four applications to explore their perception of being engaged with the technology. Results indicate that engagement is a process comprised of four distinct stages: point of engagement, period of sustained engagement, disengagement, and reengagement. Furthermore, the process is characterized by attributes of engagement that pertain to the user, the system, and user-system interaction. We also found evidence of the factors that contribute to nonengagement. Emerging from this research is a definition of engagement—a term not defined consistently in past work—as a quality of user experience characterized by attributes of challenge, positive affect, endurability, aesthetic and sensory appeal, attention, feedback, variety/novelty, interactivity, and perceived user control. This exploratory work provides the foundation for future work to test the conceptual model in various application areas, and to develop methods to measure engaging user experiences.</blockquote>

[[Category: User Experience]]
[[Category: Trust]]

User Engagement

2021-08-17T21:49:12Z

Tomjones: /* Actors */

==Full Title or Meme==
This topic takes the concept of [[User Experience]] as a deep interaction with the user over time. The intent is to help Kantara plan for the next phases 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.

===Actors===
* User
* User Delegate
* Technology vendor - provider (eg EHR)
* Technology vendor - user (eg Phone App)
* Primary Provider (original RP accessed by the user)
* Other Providers (Other web sites that were not on the user's original agenda)

The objective is to focus the discussion between the user and the site that the user wants to access.

==Proofs==
===Context===
* A statement of the set of rules that apply to the current interchanges. (eg US Healthcare HIPAA)

===User Authentication===
is the traditional role for an Identifier provider (IdP). In some ways it becomes an anachronism as we disassemble, enhance and reassemble the parts below into a complete [[User Engagement]].

===Identity Proofing===
is the process of binding an identifier to a real-world person. At its core [[Identity Proofing]] is just a comparison of biometric factors of the real-world person to some subset of the user credentials that are accumulated over a user's life-time.

===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.
===Notice and Consent===
* How is the patient informed of the transfer of information between providers with a frequency and level of detail that understands the user's expectations.
* Notice can be contemporaneous with the interaction, or can occur later if an event occurs at the RP or in a receipt of some sort that the user can view if questions about the interaction arise later.

==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 attacker 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 use of only 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.
# User Managed Access
# Consent Receipt
# Mobile Authentication Assurance Statement.
# [https://docs.kantarainitiative.org/PImDL-V1-Final.html 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 considered 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.
# The consent receipt is being expanded into
## a consent record.
## a generalized notification.
# The MAAS is being bound, in-real-time, into:
## proof that the user is present at the device
## proof that the software running on the device is same code that received the MAAS
## current device configuration that describes security settings (not user settings.)

==References==

===Research===
* [https://asistdl.onlinelibrary.wiley.com/doi/abs/10.1002/asi.20801 What is user engagement? A conceptual framework for defining user engagement with technology] <blockquote>The purpose of this article is to critically deconstruct the term engagement as it applies to peoples' experiences with technology. Through an extensive, critical multidisciplinary literature review and exploratory study of users of Web searching, online shopping, Webcasting, and gaming applications, we conceptually and operationally defined engagement. Building on past research, we conducted semistructured interviews with the users of four applications to explore their perception of being engaged with the technology. Results indicate that engagement is a process comprised of four distinct stages: point of engagement, period of sustained engagement, disengagement, and reengagement. Furthermore, the process is characterized by attributes of engagement that pertain to the user, the system, and user-system interaction. We also found evidence of the factors that contribute to nonengagement. Emerging from this research is a definition of engagement—a term not defined consistently in past work—as a quality of user experience characterized by attributes of challenge, positive affect, endurability, aesthetic and sensory appeal, attention, feedback, variety/novelty, interactivity, and perceived user control. This exploratory work provides the foundation for future work to test the conceptual model in various application areas, and to develop methods to measure engaging user experiences.</blockquote>

[[Category: User Experience]]
[[Category: Trust]]

User Engagement

2021-08-17T21:46:57Z

Tomjones: /* Actors */

==Full Title or Meme==
This topic takes the concept of [[User Experience]] as a deep interaction with the user over time. The intent is to help Kantara plan for the next phases 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.

===Actors===
* User
* User Delegate
* Technology vendor - provider (eg EHR)
* Technology vendor - user (eg Phone App)
* Primary Provider (original RP accessed by the user)
* Other Providers (Other web sites that were not on the user's original agenda)

The objective is to keep the discussion between the user and the site that the user wants to access.

==Proofs==
===Context===
* A statement of the set of rules that apply to the current interchanges. (eg US Healthcare HIPAA)

===User Authentication===
is the traditional role for an Identifier provider (IdP). In some ways it becomes an anachronism as we disassemble, enhance and reassemble the parts below into a complete [[User Engagement]].

===Identity Proofing===
is the process of binding an identifier to a real-world person. At its core [[Identity Proofing]] is just a comparison of biometric factors of the real-world person to some subset of the user credentials that are accumulated over a user's life-time.

===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.
===Notice and Consent===
* How is the patient informed of the transfer of information between providers with a frequency and level of detail that understands the user's expectations.
* Notice can be contemporaneous with the interaction, or can occur later if an event occurs at the RP or in a receipt of some sort that the user can view if questions about the interaction arise later.

==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 attacker 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 use of only 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.
# User Managed Access
# Consent Receipt
# Mobile Authentication Assurance Statement.
# [https://docs.kantarainitiative.org/PImDL-V1-Final.html 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 considered 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.
# The consent receipt is being expanded into
## a consent record.
## a generalized notification.
# The MAAS is being bound, in-real-time, into:
## proof that the user is present at the device
## proof that the software running on the device is same code that received the MAAS
## current device configuration that describes security settings (not user settings.)

==References==

===Research===
* [https://asistdl.onlinelibrary.wiley.com/doi/abs/10.1002/asi.20801 What is user engagement? A conceptual framework for defining user engagement with technology] <blockquote>The purpose of this article is to critically deconstruct the term engagement as it applies to peoples' experiences with technology. Through an extensive, critical multidisciplinary literature review and exploratory study of users of Web searching, online shopping, Webcasting, and gaming applications, we conceptually and operationally defined engagement. Building on past research, we conducted semistructured interviews with the users of four applications to explore their perception of being engaged with the technology. Results indicate that engagement is a process comprised of four distinct stages: point of engagement, period of sustained engagement, disengagement, and reengagement. Furthermore, the process is characterized by attributes of engagement that pertain to the user, the system, and user-system interaction. We also found evidence of the factors that contribute to nonengagement. Emerging from this research is a definition of engagement—a term not defined consistently in past work—as a quality of user experience characterized by attributes of challenge, positive affect, endurability, aesthetic and sensory appeal, attention, feedback, variety/novelty, interactivity, and perceived user control. This exploratory work provides the foundation for future work to test the conceptual model in various application areas, and to develop methods to measure engaging user experiences.</blockquote>

[[Category: User Experience]]
[[Category: Trust]]

User Engagement

2021-08-17T20:22:42Z

Tomjones: /* Notice and Consent */

==Full Title or Meme==
This topic takes the concept of [[User Experience]] as a deep interaction with the user over time. The intent is to help Kantara plan for the next phases 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.

===Actors===
* User
* User Delegate
* Technology vendor - provider (eg EHR)
* Technology vendor - user (eg Phone App)
* Primary Provider
* Other Providers

KISS

==Proofs==
===Context===
* A statement of the set of rules that apply to the current interchanges. (eg US Healthcare HIPAA)

===User Authentication===
is the traditional role for an Identifier provider (IdP). In some ways it becomes an anachronism as we disassemble, enhance and reassemble the parts below into a complete [[User Engagement]].

===Identity Proofing===
is the process of binding an identifier to a real-world person. At its core [[Identity Proofing]] is just a comparison of biometric factors of the real-world person to some subset of the user credentials that are accumulated over a user's life-time.

===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.
===Notice and Consent===
* How is the patient informed of the transfer of information between providers with a frequency and level of detail that understands the user's expectations.
* Notice can be contemporaneous with the interaction, or can occur later if an event occurs at the RP or in a receipt of some sort that the user can view if questions about the interaction arise later.

==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 attacker 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 use of only 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.
# User Managed Access
# Consent Receipt
# Mobile Authentication Assurance Statement.
# [https://docs.kantarainitiative.org/PImDL-V1-Final.html 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 considered 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.
# The consent receipt is being expanded into
## a consent record.
## a generalized notification.
# The MAAS is being bound, in-real-time, into:
## proof that the user is present at the device
## proof that the software running on the device is same code that received the MAAS
## current device configuration that describes security settings (not user settings.)

==References==

===Research===
* [https://asistdl.onlinelibrary.wiley.com/doi/abs/10.1002/asi.20801 What is user engagement? A conceptual framework for defining user engagement with technology] <blockquote>The purpose of this article is to critically deconstruct the term engagement as it applies to peoples' experiences with technology. Through an extensive, critical multidisciplinary literature review and exploratory study of users of Web searching, online shopping, Webcasting, and gaming applications, we conceptually and operationally defined engagement. Building on past research, we conducted semistructured interviews with the users of four applications to explore their perception of being engaged with the technology. Results indicate that engagement is a process comprised of four distinct stages: point of engagement, period of sustained engagement, disengagement, and reengagement. Furthermore, the process is characterized by attributes of engagement that pertain to the user, the system, and user-system interaction. We also found evidence of the factors that contribute to nonengagement. Emerging from this research is a definition of engagement—a term not defined consistently in past work—as a quality of user experience characterized by attributes of challenge, positive affect, endurability, aesthetic and sensory appeal, attention, feedback, variety/novelty, interactivity, and perceived user control. This exploratory work provides the foundation for future work to test the conceptual model in various application areas, and to develop methods to measure engaging user experiences.</blockquote>

[[Category: User Experience]]
[[Category: Trust]]

User Engagement

2021-08-17T20:21:34Z

Tomjones: /* Notice and Consent */

==Full Title or Meme==
This topic takes the concept of [[User Experience]] as a deep interaction with the user over time. The intent is to help Kantara plan for the next phases 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.

===Actors===
* User
* User Delegate
* Technology vendor - provider (eg EHR)
* Technology vendor - user (eg Phone App)
* Primary Provider
* Other Providers

KISS

==Proofs==
===Context===
* A statement of the set of rules that apply to the current interchanges. (eg US Healthcare HIPAA)

===User Authentication===
is the traditional role for an Identifier provider (IdP). In some ways it becomes an anachronism as we disassemble, enhance and reassemble the parts below into a complete [[User Engagement]].

===Identity Proofing===
is the process of binding an identifier to a real-world person. At its core [[Identity Proofing]] is just a comparison of biometric factors of the real-world person to some subset of the user credentials that are accumulated over a user's life-time.

===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.
===Notice and Consent===
* How is the patient informed of the transfer of information between providers with a frequency and level of detail that understands the user's expectations.
* Notice can be contemporaneous with the interaction, or can occur later if an event occurs at the RP or in a receipt of some sort that the user can view if question about the interaction arise later.

==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 attacker 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 use of only 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.
# User Managed Access
# Consent Receipt
# Mobile Authentication Assurance Statement.
# [https://docs.kantarainitiative.org/PImDL-V1-Final.html 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 considered 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.
# The consent receipt is being expanded into
## a consent record.
## a generalized notification.
# The MAAS is being bound, in-real-time, into:
## proof that the user is present at the device
## proof that the software running on the device is same code that received the MAAS
## current device configuration that describes security settings (not user settings.)

==References==

===Research===
* [https://asistdl.onlinelibrary.wiley.com/doi/abs/10.1002/asi.20801 What is user engagement? A conceptual framework for defining user engagement with technology] <blockquote>The purpose of this article is to critically deconstruct the term engagement as it applies to peoples' experiences with technology. Through an extensive, critical multidisciplinary literature review and exploratory study of users of Web searching, online shopping, Webcasting, and gaming applications, we conceptually and operationally defined engagement. Building on past research, we conducted semistructured interviews with the users of four applications to explore their perception of being engaged with the technology. Results indicate that engagement is a process comprised of four distinct stages: point of engagement, period of sustained engagement, disengagement, and reengagement. Furthermore, the process is characterized by attributes of engagement that pertain to the user, the system, and user-system interaction. We also found evidence of the factors that contribute to nonengagement. Emerging from this research is a definition of engagement—a term not defined consistently in past work—as a quality of user experience characterized by attributes of challenge, positive affect, endurability, aesthetic and sensory appeal, attention, feedback, variety/novelty, interactivity, and perceived user control. This exploratory work provides the foundation for future work to test the conceptual model in various application areas, and to develop methods to measure engaging user experiences.</blockquote>

[[Category: User Experience]]
[[Category: Trust]]

User Engagement

2021-08-17T20:18:54Z

Tomjones:

==Full Title or Meme==
This topic takes the concept of [[User Experience]] as a deep interaction with the user over time. The intent is to help Kantara plan for the next phases 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.

===Actors===
* User
* User Delegate
* Technology vendor - provider (eg EHR)
* Technology vendor - user (eg Phone App)
* Primary Provider
* Other Providers

KISS

==Proofs==
===Context===
* A statement of the set of rules that apply to the current interchanges. (eg US Healthcare HIPAA)

===User Authentication===
is the traditional role for an Identifier provider (IdP). In some ways it becomes an anachronism as we disassemble, enhance and reassemble the parts below into a complete [[User Engagement]].

===Identity Proofing===
is the process of binding an identifier to a real-world person. At its core [[Identity Proofing]] is just a comparison of biometric factors of the real-world person to some subset of the user credentials that are accumulated over a user's life-time.

===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.
===Notice and Consent===
* How is the patient informed of the transfer of information between providers with a frequency and level of detail that understands the user's expectations.

==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 attacker 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 use of only 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.
# User Managed Access
# Consent Receipt
# Mobile Authentication Assurance Statement.
# [https://docs.kantarainitiative.org/PImDL-V1-Final.html 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 considered 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.
# The consent receipt is being expanded into
## a consent record.
## a generalized notification.
# The MAAS is being bound, in-real-time, into:
## proof that the user is present at the device
## proof that the software running on the device is same code that received the MAAS
## current device configuration that describes security settings (not user settings.)

==References==

===Research===
* [https://asistdl.onlinelibrary.wiley.com/doi/abs/10.1002/asi.20801 What is user engagement? A conceptual framework for defining user engagement with technology] <blockquote>The purpose of this article is to critically deconstruct the term engagement as it applies to peoples' experiences with technology. Through an extensive, critical multidisciplinary literature review and exploratory study of users of Web searching, online shopping, Webcasting, and gaming applications, we conceptually and operationally defined engagement. Building on past research, we conducted semistructured interviews with the users of four applications to explore their perception of being engaged with the technology. Results indicate that engagement is a process comprised of four distinct stages: point of engagement, period of sustained engagement, disengagement, and reengagement. Furthermore, the process is characterized by attributes of engagement that pertain to the user, the system, and user-system interaction. We also found evidence of the factors that contribute to nonengagement. Emerging from this research is a definition of engagement—a term not defined consistently in past work—as a quality of user experience characterized by attributes of challenge, positive affect, endurability, aesthetic and sensory appeal, attention, feedback, variety/novelty, interactivity, and perceived user control. This exploratory work provides the foundation for future work to test the conceptual model in various application areas, and to develop methods to measure engaging user experiences.</blockquote>

[[Category: User Experience]]
[[Category: Trust]]

User Engagement

2021-08-17T17:50:07Z

Tomjones: /* Actors */

==Full Title or Meme==
This topic takes the concept of [[User Experience]] as a deep interaction with the user over time. The intent is to help Kantara plan for the next phases 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.

===Actors===
* User
* User Delegate
* Technology vendor - provider (eg EHR)
* Technology vendor - user (eg Phone App)
* Primary Provider
* Other Providers

KISS

==Proofs==
===Context===
* A statement of the set of rules that apply to the current interchanges. (eg US Healthcare HIPAA)
===Identity Proofing===
is the process of binding an identifier to a real-world person. At its core [[Identity Proofing]] is just a comparison of biometric factors of the real-world person to some subset of the user credentials that are accumulated over a user's life-time.

===User Authentication===
is the traditional role for an Identifier provider (IdP). In some ways it becomes an anachronism as we disassemble, enhance and reassemble 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.
===Notice and Consent===
* How is the patient informed of the transfer of information between providers with a frequency and level of detail that understands the user's expectations.

==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 attacker 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 use of only 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.
# User Managed Access
# Consent Receipt
# Mobile Authentication Assurance Statement.
# [https://docs.kantarainitiative.org/PImDL-V1-Final.html 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 considered 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.
# The consent receipt is being expanded into
## a consent record.
## a generalized notification.
# The MAAS is being bound, in-real-time, into:
## proof that the user is present at the device
## proof that the software running on the device is same code that received the MAAS
## current device configuration that describes security settings (not user settings.)

==References==

===Research===
* [https://asistdl.onlinelibrary.wiley.com/doi/abs/10.1002/asi.20801 What is user engagement? A conceptual framework for defining user engagement with technology] <blockquote>The purpose of this article is to critically deconstruct the term engagement as it applies to peoples' experiences with technology. Through an extensive, critical multidisciplinary literature review and exploratory study of users of Web searching, online shopping, Webcasting, and gaming applications, we conceptually and operationally defined engagement. Building on past research, we conducted semistructured interviews with the users of four applications to explore their perception of being engaged with the technology. Results indicate that engagement is a process comprised of four distinct stages: point of engagement, period of sustained engagement, disengagement, and reengagement. Furthermore, the process is characterized by attributes of engagement that pertain to the user, the system, and user-system interaction. We also found evidence of the factors that contribute to nonengagement. Emerging from this research is a definition of engagement—a term not defined consistently in past work—as a quality of user experience characterized by attributes of challenge, positive affect, endurability, aesthetic and sensory appeal, attention, feedback, variety/novelty, interactivity, and perceived user control. This exploratory work provides the foundation for future work to test the conceptual model in various application areas, and to develop methods to measure engaging user experiences.</blockquote>

[[Category: User Experience]]
[[Category: Trust]]

User Engagement

2021-08-17T17:40:51Z

Tomjones: /* Proofs */

==Full Title or Meme==
This topic takes the concept of [[User Experience]] as a deep interaction with the user over time. The intent is to help Kantara plan for the next phases 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.

===Actors===
* User
* User Delegate
* Technology vendor (eg EHR)
* Primary Provider
* Other Providers

KISS

==Proofs==
===Context===
* A statement of the set of rules that apply to the current interchanges. (eg US Healthcare HIPAA)
===Identity Proofing===
is the process of binding an identifier to a real-world person. At its core [[Identity Proofing]] is just a comparison of biometric factors of the real-world person to some subset of the user credentials that are accumulated over a user's life-time.

===User Authentication===
is the traditional role for an Identifier provider (IdP). In some ways it becomes an anachronism as we disassemble, enhance and reassemble 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.
===Notice and Consent===
* How is the patient informed of the transfer of information between providers with a frequency and level of detail that understands the user's expectations.

==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 attacker 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 use of only 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.
# User Managed Access
# Consent Receipt
# Mobile Authentication Assurance Statement.
# [https://docs.kantarainitiative.org/PImDL-V1-Final.html 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 considered 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.
# The consent receipt is being expanded into
## a consent record.
## a generalized notification.
# The MAAS is being bound, in-real-time, into:
## proof that the user is present at the device
## proof that the software running on the device is same code that received the MAAS
## current device configuration that describes security settings (not user settings.)

==References==

===Research===
* [https://asistdl.onlinelibrary.wiley.com/doi/abs/10.1002/asi.20801 What is user engagement? A conceptual framework for defining user engagement with technology] <blockquote>The purpose of this article is to critically deconstruct the term engagement as it applies to peoples' experiences with technology. Through an extensive, critical multidisciplinary literature review and exploratory study of users of Web searching, online shopping, Webcasting, and gaming applications, we conceptually and operationally defined engagement. Building on past research, we conducted semistructured interviews with the users of four applications to explore their perception of being engaged with the technology. Results indicate that engagement is a process comprised of four distinct stages: point of engagement, period of sustained engagement, disengagement, and reengagement. Furthermore, the process is characterized by attributes of engagement that pertain to the user, the system, and user-system interaction. We also found evidence of the factors that contribute to nonengagement. Emerging from this research is a definition of engagement—a term not defined consistently in past work—as a quality of user experience characterized by attributes of challenge, positive affect, endurability, aesthetic and sensory appeal, attention, feedback, variety/novelty, interactivity, and perceived user control. This exploratory work provides the foundation for future work to test the conceptual model in various application areas, and to develop methods to measure engaging user experiences.</blockquote>

[[Category: User Experience]]
[[Category: Trust]]

User Engagement

2021-08-17T17:34:57Z

Tomjones: /* Notice and Consent */

==Full Title or Meme==
This topic takes the concept of [[User Experience]] as a deep interaction with the user over time. The intent is to help Kantara plan for the next phases 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.

===Actors===
* User
* User Delegate
* Technology vendor (eg EHR)
* Primary Provider
* Other Providers

KISS

==Proofs==
===Identity Proofing===
is the process of binding an identifier to a real-world person. At its core [[Identity Proofing]] is just a comparison of biometric factors of the real-world person to some subset of the user credentials that are accumulated over a user's life-time.

===User Authentication===
is the traditional role for an Identifier provider (IdP). In some ways it becomes an anachronism as we disassemble, enhance and reassemble 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.
===Notice and Consent===
* How is the patient informed of the transfer of information between providers with a frequency and level of detail that understands the user's expectations.

==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 attacker 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 use of only 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.
# User Managed Access
# Consent Receipt
# Mobile Authentication Assurance Statement.
# [https://docs.kantarainitiative.org/PImDL-V1-Final.html 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 considered 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.
# The consent receipt is being expanded into
## a consent record.
## a generalized notification.
# The MAAS is being bound, in-real-time, into:
## proof that the user is present at the device
## proof that the software running on the device is same code that received the MAAS
## current device configuration that describes security settings (not user settings.)

==References==

===Research===
* [https://asistdl.onlinelibrary.wiley.com/doi/abs/10.1002/asi.20801 What is user engagement? A conceptual framework for defining user engagement with technology] <blockquote>The purpose of this article is to critically deconstruct the term engagement as it applies to peoples' experiences with technology. Through an extensive, critical multidisciplinary literature review and exploratory study of users of Web searching, online shopping, Webcasting, and gaming applications, we conceptually and operationally defined engagement. Building on past research, we conducted semistructured interviews with the users of four applications to explore their perception of being engaged with the technology. Results indicate that engagement is a process comprised of four distinct stages: point of engagement, period of sustained engagement, disengagement, and reengagement. Furthermore, the process is characterized by attributes of engagement that pertain to the user, the system, and user-system interaction. We also found evidence of the factors that contribute to nonengagement. Emerging from this research is a definition of engagement—a term not defined consistently in past work—as a quality of user experience characterized by attributes of challenge, positive affect, endurability, aesthetic and sensory appeal, attention, feedback, variety/novelty, interactivity, and perceived user control. This exploratory work provides the foundation for future work to test the conceptual model in various application areas, and to develop methods to measure engaging user experiences.</blockquote>

[[Category: User Experience]]
[[Category: Trust]]

User Engagement

2021-08-17T17:31:58Z

Tomjones: /* Currency */

==Full Title or Meme==
This topic takes the concept of [[User Experience]] as a deep interaction with the user over time. The intent is to help Kantara plan for the next phases 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.

===Actors===
* User
* User Delegate
* Technology vendor (eg EHR)
* Primary Provider
* Other Providers

KISS

==Proofs==
===Identity Proofing===
is the process of binding an identifier to a real-world person. At its core [[Identity Proofing]] is just a comparison of biometric factors of the real-world person to some subset of the user credentials that are accumulated over a user's life-time.

===User Authentication===
is the traditional role for an Identifier provider (IdP). In some ways it becomes an anachronism as we disassemble, enhance and reassemble 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.
===Notice and Consent===
* How is the patient informed of the transfer of information between providers.

==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 attacker 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 use of only 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.
# User Managed Access
# Consent Receipt
# Mobile Authentication Assurance Statement.
# [https://docs.kantarainitiative.org/PImDL-V1-Final.html 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 considered 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.
# The consent receipt is being expanded into
## a consent record.
## a generalized notification.
# The MAAS is being bound, in-real-time, into:
## proof that the user is present at the device
## proof that the software running on the device is same code that received the MAAS
## current device configuration that describes security settings (not user settings.)

==References==

===Research===
* [https://asistdl.onlinelibrary.wiley.com/doi/abs/10.1002/asi.20801 What is user engagement? A conceptual framework for defining user engagement with technology] <blockquote>The purpose of this article is to critically deconstruct the term engagement as it applies to peoples' experiences with technology. Through an extensive, critical multidisciplinary literature review and exploratory study of users of Web searching, online shopping, Webcasting, and gaming applications, we conceptually and operationally defined engagement. Building on past research, we conducted semistructured interviews with the users of four applications to explore their perception of being engaged with the technology. Results indicate that engagement is a process comprised of four distinct stages: point of engagement, period of sustained engagement, disengagement, and reengagement. Furthermore, the process is characterized by attributes of engagement that pertain to the user, the system, and user-system interaction. We also found evidence of the factors that contribute to nonengagement. Emerging from this research is a definition of engagement—a term not defined consistently in past work—as a quality of user experience characterized by attributes of challenge, positive affect, endurability, aesthetic and sensory appeal, attention, feedback, variety/novelty, interactivity, and perceived user control. This exploratory work provides the foundation for future work to test the conceptual model in various application areas, and to develop methods to measure engaging user experiences.</blockquote>

[[Category: User Experience]]
[[Category: Trust]]

User Engagement

2021-08-17T17:31:02Z

Tomjones: /* Currency */

==Full Title or Meme==
This topic takes the concept of [[User Experience]] as a deep interaction with the user over time. The intent is to help Kantara plan for the next phases 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.

===Actors===
* User
* User Delegate
* Technology vendor (eg EHR)
* Primary Provider
* Other Providers

KISS

==Proofs==
===Identity Proofing===
is the process of binding an identifier to a real-world person. At its core [[Identity Proofing]] is just a comparison of biometric factors of the real-world person to some subset of the user credentials that are accumulated over a user's life-time.

===User Authentication===
is the traditional role for an Identifier provider (IdP). In some ways it becomes an anachronism as we disassemble, enhance and reassemble 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.
===Notice and Consent
* How is the patient informed of the transfer of information between providers.

==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 attacker 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 use of only 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.
# User Managed Access
# Consent Receipt
# Mobile Authentication Assurance Statement.
# [https://docs.kantarainitiative.org/PImDL-V1-Final.html 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 considered 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.
# The consent receipt is being expanded into
## a consent record.
## a generalized notification.
# The MAAS is being bound, in-real-time, into:
## proof that the user is present at the device
## proof that the software running on the device is same code that received the MAAS
## current device configuration that describes security settings (not user settings.)

==References==

===Research===
* [https://asistdl.onlinelibrary.wiley.com/doi/abs/10.1002/asi.20801 What is user engagement? A conceptual framework for defining user engagement with technology] <blockquote>The purpose of this article is to critically deconstruct the term engagement as it applies to peoples' experiences with technology. Through an extensive, critical multidisciplinary literature review and exploratory study of users of Web searching, online shopping, Webcasting, and gaming applications, we conceptually and operationally defined engagement. Building on past research, we conducted semistructured interviews with the users of four applications to explore their perception of being engaged with the technology. Results indicate that engagement is a process comprised of four distinct stages: point of engagement, period of sustained engagement, disengagement, and reengagement. Furthermore, the process is characterized by attributes of engagement that pertain to the user, the system, and user-system interaction. We also found evidence of the factors that contribute to nonengagement. Emerging from this research is a definition of engagement—a term not defined consistently in past work—as a quality of user experience characterized by attributes of challenge, positive affect, endurability, aesthetic and sensory appeal, attention, feedback, variety/novelty, interactivity, and perceived user control. This exploratory work provides the foundation for future work to test the conceptual model in various application areas, and to develop methods to measure engaging user experiences.</blockquote>

[[Category: User Experience]]
[[Category: Trust]]

User Engagement

2021-08-17T17:23:39Z

Tomjones: /* Actors */

==Full Title or Meme==
This topic takes the concept of [[User Experience]] as a deep interaction with the user over time. The intent is to help Kantara plan for the next phases 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.

===Actors===
* User
* User Delegate
* Technology vendor (eg EHR)
* Primary Provider
* Other Providers

KISS

==Proofs==
===Identity Proofing===
is the process of binding an identifier to a real-world person. At its core [[Identity Proofing]] is just a comparison of biometric factors of the real-world person to some subset of the user credentials that are accumulated over a user's life-time.

===User Authentication===
is the traditional role for an Identifier provider (IdP). In some ways it becomes an anachronism as we disassemble, enhance and reassemble 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 attacker 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 use of only 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.
# User Managed Access
# Consent Receipt
# Mobile Authentication Assurance Statement.
# [https://docs.kantarainitiative.org/PImDL-V1-Final.html 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 considered 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.
# The consent receipt is being expanded into
## a consent record.
## a generalized notification.
# The MAAS is being bound, in-real-time, into:
## proof that the user is present at the device
## proof that the software running on the device is same code that received the MAAS
## current device configuration that describes security settings (not user settings.)

==References==

===Research===
* [https://asistdl.onlinelibrary.wiley.com/doi/abs/10.1002/asi.20801 What is user engagement? A conceptual framework for defining user engagement with technology] <blockquote>The purpose of this article is to critically deconstruct the term engagement as it applies to peoples' experiences with technology. Through an extensive, critical multidisciplinary literature review and exploratory study of users of Web searching, online shopping, Webcasting, and gaming applications, we conceptually and operationally defined engagement. Building on past research, we conducted semistructured interviews with the users of four applications to explore their perception of being engaged with the technology. Results indicate that engagement is a process comprised of four distinct stages: point of engagement, period of sustained engagement, disengagement, and reengagement. Furthermore, the process is characterized by attributes of engagement that pertain to the user, the system, and user-system interaction. We also found evidence of the factors that contribute to nonengagement. Emerging from this research is a definition of engagement—a term not defined consistently in past work—as a quality of user experience characterized by attributes of challenge, positive affect, endurability, aesthetic and sensory appeal, attention, feedback, variety/novelty, interactivity, and perceived user control. This exploratory work provides the foundation for future work to test the conceptual model in various application areas, and to develop methods to measure engaging user experiences.</blockquote>

[[Category: User Experience]]
[[Category: Trust]]

User Engagement

2021-08-17T17:22:30Z

Tomjones: /* Actors */

==Full Title or Meme==
This topic takes the concept of [[User Experience]] as a deep interaction with the user over time. The intent is to help Kantara plan for the next phases 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.

===Actors===
* User
* User Delegate
* Technology vendor (eg EHR)
* Primary Care Provider
* Other Providers

==Proofs==
===Identity Proofing===
is the process of binding an identifier to a real-world person. At its core [[Identity Proofing]] is just a comparison of biometric factors of the real-world person to some subset of the user credentials that are accumulated over a user's life-time.

===User Authentication===
is the traditional role for an Identifier provider (IdP). In some ways it becomes an anachronism as we disassemble, enhance and reassemble 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 attacker 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 use of only 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.
# User Managed Access
# Consent Receipt
# Mobile Authentication Assurance Statement.
# [https://docs.kantarainitiative.org/PImDL-V1-Final.html 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 considered 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.
# The consent receipt is being expanded into
## a consent record.
## a generalized notification.
# The MAAS is being bound, in-real-time, into:
## proof that the user is present at the device
## proof that the software running on the device is same code that received the MAAS
## current device configuration that describes security settings (not user settings.)

==References==

===Research===
* [https://asistdl.onlinelibrary.wiley.com/doi/abs/10.1002/asi.20801 What is user engagement? A conceptual framework for defining user engagement with technology] <blockquote>The purpose of this article is to critically deconstruct the term engagement as it applies to peoples' experiences with technology. Through an extensive, critical multidisciplinary literature review and exploratory study of users of Web searching, online shopping, Webcasting, and gaming applications, we conceptually and operationally defined engagement. Building on past research, we conducted semistructured interviews with the users of four applications to explore their perception of being engaged with the technology. Results indicate that engagement is a process comprised of four distinct stages: point of engagement, period of sustained engagement, disengagement, and reengagement. Furthermore, the process is characterized by attributes of engagement that pertain to the user, the system, and user-system interaction. We also found evidence of the factors that contribute to nonengagement. Emerging from this research is a definition of engagement—a term not defined consistently in past work—as a quality of user experience characterized by attributes of challenge, positive affect, endurability, aesthetic and sensory appeal, attention, feedback, variety/novelty, interactivity, and perceived user control. This exploratory work provides the foundation for future work to test the conceptual model in various application areas, and to develop methods to measure engaging user experiences.</blockquote>

[[Category: User Experience]]
[[Category: Trust]]

User Engagement

2021-08-17T17:19:40Z

Tomjones: /* What this is NOT about */

==Full Title or Meme==
This topic takes the concept of [[User Experience]] as a deep interaction with the user over time. The intent is to help Kantara plan for the next phases 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.

===Actors===
* user
* Technology vendor (eg EHR)
* Primary Care Provider
* Other Providers

==Proofs==
===Identity Proofing===
is the process of binding an identifier to a real-world person. At its core [[Identity Proofing]] is just a comparison of biometric factors of the real-world person to some subset of the user credentials that are accumulated over a user's life-time.

===User Authentication===
is the traditional role for an Identifier provider (IdP). In some ways it becomes an anachronism as we disassemble, enhance and reassemble 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 attacker 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 use of only 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.
# User Managed Access
# Consent Receipt
# Mobile Authentication Assurance Statement.
# [https://docs.kantarainitiative.org/PImDL-V1-Final.html 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 considered 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.
# The consent receipt is being expanded into
## a consent record.
## a generalized notification.
# The MAAS is being bound, in-real-time, into:
## proof that the user is present at the device
## proof that the software running on the device is same code that received the MAAS
## current device configuration that describes security settings (not user settings.)

==References==

===Research===
* [https://asistdl.onlinelibrary.wiley.com/doi/abs/10.1002/asi.20801 What is user engagement? A conceptual framework for defining user engagement with technology] <blockquote>The purpose of this article is to critically deconstruct the term engagement as it applies to peoples' experiences with technology. Through an extensive, critical multidisciplinary literature review and exploratory study of users of Web searching, online shopping, Webcasting, and gaming applications, we conceptually and operationally defined engagement. Building on past research, we conducted semistructured interviews with the users of four applications to explore their perception of being engaged with the technology. Results indicate that engagement is a process comprised of four distinct stages: point of engagement, period of sustained engagement, disengagement, and reengagement. Furthermore, the process is characterized by attributes of engagement that pertain to the user, the system, and user-system interaction. We also found evidence of the factors that contribute to nonengagement. Emerging from this research is a definition of engagement—a term not defined consistently in past work—as a quality of user experience characterized by attributes of challenge, positive affect, endurability, aesthetic and sensory appeal, attention, feedback, variety/novelty, interactivity, and perceived user control. This exploratory work provides the foundation for future work to test the conceptual model in various application areas, and to develop methods to measure engaging user experiences.</blockquote>

[[Category: User Experience]]
[[Category: Trust]]

Patient Empowerment

2021-08-17T16:21:32Z

Tomjones: /* Full Title or Meme */

==Full Title or Meme==
[[Patient Empowerment]] is about asserting what a healthcare patient CAN do. [[User Engagement‎‎]] is a discussion about what a patient SHOULD do.

==References==

[[Category: Profile]]
[[Category: Health]]

Patient Empowerment

2021-08-17T16:21:12Z

Tomjones: /* Full Title or Meme */

==Full Title or Meme==
[[Patient Empowerment]] is about asserting what a healthcare patient CAN do. [[User Engagement‎‎ Engagement]] is a discussion about what a patient SHOULD do.

==References==

[[Category: Profile]]
[[Category: Health]]

Patient Empowerment

2021-08-17T16:20:03Z

Tomjones: /* Full Title or Meme */

==Full Title or Meme==
[[Patient Empowerment]] is about asserting what a healthcare patient CAN do. [[Patient Engagement]] is a discussion about what a user SHOULD do.

==References==

[[Category: Profile]]
[[Category: Health]]

Patient Empowerment

2021-08-17T16:19:42Z

Tomjones: Created page with "==Full Title or Meme== Patient Empowerment is about asserting what a healthcare patient CAN do. Patient Emgagement is a discussion about what a user SHOULD do. ==Re..."

==Full Title or Meme==
[[Patient Empowerment]] is about asserting what a healthcare patient CAN do. [[Patient Emgagement]] is a discussion about what a user SHOULD do.

==References==

[[Category: Profile]]
[[Category: Health]]

Verification of Software

2021-08-17T16:11:09Z

Tomjones: /* References */

==Full Title or Meme==
[https://www.nist.gov/document/document-developer-verification-software Recommended Minimum Standards for Vendor or Developer Verification (Testing) of Software Under Executive Order (EO) 14028 - PDF Version]

==Context==
* Executive Order (EO) 14028 on Improving the Nation’s Cybersecurity, May 12, 2021, directs the National Institute of Standards and Technology (NIST) to publish guidelines on vendors’ source code testing.<blockquote>Section 4(r) Within 60 days of the date of this order, the Secretary of Commerce acting through the Director of NIST, in consultation with the Secretary of Defense acting through the Director of the NSA, shall publish guidelines recommending minimum standards for vendors’ testing of their software source code, including identifying recommended types of manual or automated testing (such as code review tools, static and dynamic analysis, software composition tools, and penetration testing).</blockquote>

==Tasks and Timelines==
# 2021-06-29 Publish definition of "critical software"
# 2021-07-11 Publish guidance outlining security measures for security measures for coital software (vendor testing of SW source code)
# 2021-11-08 Publish preliminary guidelines
# 2022-02-06 Issue guidance identifying practice that enhance security of software.
# 2022-05-08 Publish guidelines with review/update procedures.
# 2022-05-13 Review and submit summary report of pilot programs

==References==

[[Category: Standard]]

Verification of Software

2021-08-17T16:00:26Z

Tomjones: Created page with "==Full Title or Meme== [https://www.nist.gov/document/document-developer-verification-software Recommended Minimum Standards for Vendor or Developer Verification (Testing) of..."

User Engagement

2021-08-17T00:27:58Z

Tomjones: /* Identity Proofing */

==Full Title or Meme==
This topic takes the concept of [[User Experience]] as a deep interaction with the user over time. The intent is to help Kantara plan for the next phases 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 an identifier to a real-world person. At its core [[Identity Proofing]] is just a comparison of biometric factors of the real-world person to some subset of the user credentials that are accumulated over a user's life-time.

===User Authentication===
is the traditional role for an Identifier provider (IdP). In some ways it becomes an anachronism as we disassemble, enhance and reassemble 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 attacker 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 use of only 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.
# User Managed Access
# Consent Receipt
# Mobile Authentication Assurance Statement.
# [https://docs.kantarainitiative.org/PImDL-V1-Final.html 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 considered 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.
# The consent receipt is being expanded into
## a consent record.
## a generalized notification.
# The MAAS is being bound, in-real-time, into:
## proof that the user is present at the device
## proof that the software running on the device is same code that received the MAAS
## current device configuration that describes security settings (not user settings.)

==References==

===Research===
* [https://asistdl.onlinelibrary.wiley.com/doi/abs/10.1002/asi.20801 What is user engagement? A conceptual framework for defining user engagement with technology] <blockquote>The purpose of this article is to critically deconstruct the term engagement as it applies to peoples' experiences with technology. Through an extensive, critical multidisciplinary literature review and exploratory study of users of Web searching, online shopping, Webcasting, and gaming applications, we conceptually and operationally defined engagement. Building on past research, we conducted semistructured interviews with the users of four applications to explore their perception of being engaged with the technology. Results indicate that engagement is a process comprised of four distinct stages: point of engagement, period of sustained engagement, disengagement, and reengagement. Furthermore, the process is characterized by attributes of engagement that pertain to the user, the system, and user-system interaction. We also found evidence of the factors that contribute to nonengagement. Emerging from this research is a definition of engagement—a term not defined consistently in past work—as a quality of user experience characterized by attributes of challenge, positive affect, endurability, aesthetic and sensory appeal, attention, feedback, variety/novelty, interactivity, and perceived user control. This exploratory work provides the foundation for future work to test the conceptual model in various application areas, and to develop methods to measure engaging user experiences.</blockquote>

[[Category: User Experience]]
[[Category: Trust]]

User Engagement

2021-08-17T00:26:27Z

Tomjones: /* Identity Proofing */

==Full Title or Meme==
This topic takes the concept of [[User Experience]] as a deep interaction with the user over time. The intent is to help Kantara plan for the next phases 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 an identifier to a real-world person. At its core [[Identity Proofing]] 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===
is the traditional role for an Identifier provider (IdP). In some ways it becomes an anachronism as we disassemble, enhance and reassemble 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 attacker 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 use of only 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.
# User Managed Access
# Consent Receipt
# Mobile Authentication Assurance Statement.
# [https://docs.kantarainitiative.org/PImDL-V1-Final.html 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 considered 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.
# The consent receipt is being expanded into
## a consent record.
## a generalized notification.
# The MAAS is being bound, in-real-time, into:
## proof that the user is present at the device
## proof that the software running on the device is same code that received the MAAS
## current device configuration that describes security settings (not user settings.)

==References==

===Research===
* [https://asistdl.onlinelibrary.wiley.com/doi/abs/10.1002/asi.20801 What is user engagement? A conceptual framework for defining user engagement with technology] <blockquote>The purpose of this article is to critically deconstruct the term engagement as it applies to peoples' experiences with technology. Through an extensive, critical multidisciplinary literature review and exploratory study of users of Web searching, online shopping, Webcasting, and gaming applications, we conceptually and operationally defined engagement. Building on past research, we conducted semistructured interviews with the users of four applications to explore their perception of being engaged with the technology. Results indicate that engagement is a process comprised of four distinct stages: point of engagement, period of sustained engagement, disengagement, and reengagement. Furthermore, the process is characterized by attributes of engagement that pertain to the user, the system, and user-system interaction. We also found evidence of the factors that contribute to nonengagement. Emerging from this research is a definition of engagement—a term not defined consistently in past work—as a quality of user experience characterized by attributes of challenge, positive affect, endurability, aesthetic and sensory appeal, attention, feedback, variety/novelty, interactivity, and perceived user control. This exploratory work provides the foundation for future work to test the conceptual model in various application areas, and to develop methods to measure engaging user experiences.</blockquote>

[[Category: User Experience]]
[[Category: Trust]]

User Engagement

2021-08-17T00:24:23Z

Tomjones: /* Sovereign Surveillance */

==Full Title or Meme==
This topic takes the concept of [[User Experience]] as a deep interaction with the user over time. The intent is to help Kantara plan for the next phases 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 an 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===
is the traditional role for an Identifier provider (IdP). In some ways it becomes an anachronism as we disassemble, enhance and reassemble 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 attacker 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 use of only 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.
# User Managed Access
# Consent Receipt
# Mobile Authentication Assurance Statement.
# [https://docs.kantarainitiative.org/PImDL-V1-Final.html 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 considered 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.
# The consent receipt is being expanded into
## a consent record.
## a generalized notification.
# The MAAS is being bound, in-real-time, into:
## proof that the user is present at the device
## proof that the software running on the device is same code that received the MAAS
## current device configuration that describes security settings (not user settings.)

==References==

===Research===
* [https://asistdl.onlinelibrary.wiley.com/doi/abs/10.1002/asi.20801 What is user engagement? A conceptual framework for defining user engagement with technology] <blockquote>The purpose of this article is to critically deconstruct the term engagement as it applies to peoples' experiences with technology. Through an extensive, critical multidisciplinary literature review and exploratory study of users of Web searching, online shopping, Webcasting, and gaming applications, we conceptually and operationally defined engagement. Building on past research, we conducted semistructured interviews with the users of four applications to explore their perception of being engaged with the technology. Results indicate that engagement is a process comprised of four distinct stages: point of engagement, period of sustained engagement, disengagement, and reengagement. Furthermore, the process is characterized by attributes of engagement that pertain to the user, the system, and user-system interaction. We also found evidence of the factors that contribute to nonengagement. Emerging from this research is a definition of engagement—a term not defined consistently in past work—as a quality of user experience characterized by attributes of challenge, positive affect, endurability, aesthetic and sensory appeal, attention, feedback, variety/novelty, interactivity, and perceived user control. This exploratory work provides the foundation for future work to test the conceptual model in various application areas, and to develop methods to measure engaging user experiences.</blockquote>

[[Category: User Experience]]
[[Category: Trust]]

VICAL

2021-08-11T00:57:23Z

Tomjones:

==Full Title==
The [[VICAL]] is the new name for the ISO 18013-5 master list of certificates for issuers (and perhaps others) for [[Mobile Driver's License]]s.

==AAMVA==
These are notes from AAMVA who may wish to implement a VICAL.

*The VICAL is
validated by verification of the VICAL signing key which will be provided to
the RPs. Any specific requirements from a governance/policy perspective
regarding the requirements that must be met for inclusion in the MVP
will be determined at a later time

==References==

[[Category: Trust]]

VICAL

2021-08-11T00:55:45Z

Tomjones: Created page with "==Full Title== The VICAL is the new name for the ISO 18013-5 master list of certificates for issuers (and perhaps others) for Mobile Driver's Licenses. ==AAMVA== Thes..."

Do Not Track

2021-08-04T01:16:27Z

Tomjones: /* Problem */

==Full Title==
'''Tracking Preference Expression (DNT)''' W3C Candidate Recommendation (2017-10-19)

==Context==
The Abstract from the standard states it best:
<blockquote>This specification defines the DNT request header field as an HTTP mechanism for expressing a user's preference regarding tracking, an HTML DOM property to make that expression readable by scripts, and APIs that allow scripts to register exceptions granted by the user. It also defines mechanisms for sites to communicate whether and how they honor a received preference, including well-known resources for retrieving preflight tracking status, a media type for representing tracking status information, and the Tk response header field for confirming tracking status.</blockquote>
==Problem==
The W3C is dominated by commercial interests that have blocked standardization of this well-known, and well-regarded (non)standard.

==Solutions==
* [https://globalprivacycontrol.org/#faq Global Privacy Control]
* [https://transcend.io/blog/ccpa-gpc-update CCPA update: Businesses must immediately support the Global Privacy Control (GPC) signal] 2021-07-21

==REFERENCES==
More information about [[Do Not Track]] can be found at these links:
*FTC website on [[Do Not Track]]: https://www.ftc.gov/public-statements/2011/10/do-not-track-privacy-internet-age
*[[Do Not Track]] standard work at the W3C: http://www.w3.org/2011/tracking-protection/