Lots of identifiers make tracking any transaction difficult even for architects

[TomCJones]

Do we need to make clear (perhaps with a list) the identifiers that get used to ensure privacy and security. 1> Medical record locator at PCP (the source of the PHI) 2> Medical record locator at Referred provider (the sink of the PHI) 3> The friendly name used only on the user's phone (or is this totally out-of-scope) 4> The subject id (sub) that is used for authentication which occurs on the user's phone - note that this could even be pair-wise unique (it is used at CSP, PCP, referred provider, anywhere that the user is registred) - another subject for discussion.

[nwhysel]

3 seems out of scope...although...we sometimes do see accounts that let you use or post a security image. I wouldn’t be surprised if some people use the nickname field in a similar way to indicate it is not a phishing site.

Noreen

—

Noreen Y. Whysel

Ask me about: The Information Architecture Conference April 14-18 in New Orleans http://www.theiaconference.com

On Dec 28, 2019, at 3:44 PM, tom jones notifications@github.com wrote:

 Do we need to make clear (perhaps with a list) the identifiers that get used to ensure privacy and security. 1> Medical record locator at PCP (the source of the PHI) 2> Medical record locator at Referred provider (the sink of the PHI) 3> The friendly name used only on the user's phone (or is this totally out-of-scope) 4> The subject id (sub) that is used for authentication which occurs on the user's phone - note that this could even be pair-wise unique (it is used at CSP, PCP, referred provider, anywhere that the user is registred) - another subject for discussion.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[TomCJones]

that might be better represented as yet a different ID - Something on the web site that they can display to me that only i would recognize - is that what you are talking about? Something i know, but is held on the web site? Although that is good - if it not in the json message - i suspect it is still out-of-scope for this doc.

[nwhysel]

Yes.

Noreen

—

Noreen Y. Whysel

Ask me about: The Information Architecture Conference April 14-18 in New Orleans http://www.theiaconference.com

On Dec 29, 2019, at 1:31 AM, tom jones notifications@github.com wrote:

 that might be better represented as yet a different ID - Something on the web site that they can display to me that only i would recognize - is that what you are talking about? Something i know, but is held on the web site?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[TomCJones]

but - we can mention these other identifiers even tho we do not describe them in detail - but what i think we really need is a ux guideline - i leave it to the group to decide if the ux guideline is in this doc or in a companion doc. One reason for it to be in a separate doc is that it can be overtly oriented to the healthcare profile (which makes it easier to create and more understandable IMHO)

[TomCJones]

how about this approach - the current doc has these sections 7Considerations (non-normative) 7.1A Distributed Assurances User Information 7.2Sensitive User Information: Liability & Compliance 7.3Security and Integrity of JSON

I propose these be replaced with 7 Considerations This spec addresses protocol interoperability as the primary objective. The following considerations are needed for a complete solutions and are offered here as suggested guidelines. 7.1 User experience considerations 7.1.1 Identifiers (non-normative) It is the objective of the user's agent to store authentication credentials and other user claims needed to provide the user with the level of assurance for identity and authentication needed for demanding web sites. Each persona that the user creates with have the level of support that it requires. For example the following personas might be appropriate for Fred if he want to have a normal persona, as well as a high assurance medical persona and to act as guardian for his under 13 year-old daughter and a parent who has arranged for him to act as guardian.

1. Fred-personal = a common self-issued persona with no special assurances.
2. Fred-medical = a high assurance self-issued persona with level 2 identity and authentication assurances for access to his own medical records. 3 Daughter-annie = a high assurance self-issued persona with level 2 identity and authentication assurances and access to Annie's medical records. 4 Grandfather-john = a high assurance self-issued persona with level 2 identity and authentication assurances for access to Fred's father's medical records.

While many use case will have multiple personas as shown above, there is no reason that a single persona user agent should not be produced as well. In any case each persona must be able to handle identity assurances from any compliant provider, and record locators at any number of other compliant providers. Acting as identifier provider for the user, the agent in the user's device may also crate any number of subject identifiers spanning a range of networks including decentralized identifiers (DIDs) defined over block chains. but none of this complexity need to be normally visible to the user. It can all be hidden inside opaque digital protocols. 7.2 Privacy considerations The major objective of this section is to assure that solution can be configured by most developers to meet the privacy requirements of the evolving privacy legislation as well as the IDEF guidelines. 7.3 Security considerations The major objective of this section is to assure that solution can be configured by most developers to meet the security requirements of the NIST 800-63-3B level AAL2 as well as the IDEF guidelines. The challenge is to encode the authentication assurances in a manner that can be reliably tested by the CSP and passed on to the relying parties. 7.3.1 Private Key Protection 7.3.1.1 Android key protection (non-normative and may change over time) The best working api for creating a Private Key in Android appears to be KeyGenParameterSpec added in Android M (API 23) as described in this post.https://doridori.github.io/android-security-the-forgetful-keystore/#sthash.NijopPIO.dpbs It is required that the Android device is protected with a device-lock set to prevent access without the code. This is a good security featured. 7.3.1.2 Apple Key Protection (non-normative and may change over time)

[TomCJones]

approved and added 2020-01-07