Create a unique page for each user where their account info will reside

[dazzaji]

This should be a individual file probably in json format per user.

To show it is working maybe add a "how many times have you logged in" feature on the page and add 1 each time that user logs in with their service. So they see the number changing.

Concept: A user who logs in can click on their name in upper right while logged in and be linked to a page representing their account mgmt and profile on the system. See README for thoughts on how that could work and be named, etc.

[akshithg]

Using mongodb to save the json records

• easy to query
• support json by default

[dazzaji]

I get what you are saying here but please try to ensure a file in a directory for each account. Sure, for performance and data management reasons there is every reason to use a database and mongo is well integrated with node. I see no problem if you want to implement a mongo database version of the information on a plain simple identity file for each account holder but for purposes of implementing an axiom-level prototype of this account module component, I think the authoritative version of identity data should reside in a unique text file for each account.

what data is in the file per account?

As a reminder: The basic data model for the account file should reflect the information in the issues. It should include or just be in JSON format. The view a user sees can render HTML from the data in JSON without ever using a database. I can show you how to do that it that would be helpful. In this way the user always see their account and identity info from the actual authoritative data source in JSON even if they are not reading the JSON and if there is a problem they can look at the file and see the information in the JSON format.

If you get to it, on the account file JSON structured objects, can you please include a placeholder for a "role" and for a "position" and also for "contact information" objects (I'll show you the formats from standard OIDC tokenized claims we can use for that so it all interoperates with Google, MIT and other standard identity service components.

Authorizations are the most important info

In the account file, the most important thing is to feature near the top of the page the then current authorizations (eg via the login with Google and/or GitHub authoritations) for each user.

For later, it would be good to support a "common name" (initially from profile) which the user should be able to update or provide a name if they don't want to use the github or google names.

Why bother with a file let account?

Consider that a technically highly performant system that is not aligned correctly with ownership, control and governance is not better. When the authoritative record representing a human's identity is a pure text file, then the person identified has simple and easily provable ways to exercise ownership and control over that information. A structured text file can be easily accessed (assuming you implement the URL per file), read, updated, copied, etc by the person identified. That authoritative data can easily and effectively and probably be understood and used in context by the person identified.

For most people, it would be very hard or impossible to when use the same control and have the same understanding of the dynamic and almost emergent data in and running through mongo at any moment or period of time. A copy of the record can be emailed to the person with a hash everytime there is a modification of the file. The file can be directly inspected by the person at every stage. The authoritative version of the file can be moved from an UnWorkshop services to an MIT or Google or Akshith server by the person and the blurb (or JSON object) of text representing the URL of the user is the only item that would need to be updated on the authoritative version.

These properties are especially important for prototyping the business and legal aspects of the identity module so it can be evaluated and understood by many collaborators in the law, in business, in research and beyond. These properties also make it very clear how to evaluate the adequacy of a mongo or other specific database or other ready-made full-blown technology as a candidate to store and manage identity.

use the data file as authoritative and database for fast performance

but ensure the database always reflect the data in the file for important transactions

So, what I recommend is that you do your best to stick to implementing the issues in the way we discussed and finalized them or note the questions or problems you encounter trying to do so. Also note ideas you have for better ways to implement the underlying goals of each issue. Note these things in the comments for each issue.

Please use the data in the file as the authoritative source of data. If you use a database too that is find but treat the data in the mongo db as solely for performance and document in the code that the authoritative data is in the file for now.

I think that later if or when a future version of the prototype is built to support important transactions then the data file will be the only record or methods will ensure the database version is always in sync with the data file before it is used for important transactions.

[dazzaji]

Hey there - my comment came in after you closed the issue. Can you update on this please?

[akshithg]

@dazzaji I get the point. I think we should go with the approach where we have both the database and a file. I understand why we need a single file per user. Having a database helps in the process of application development. I can probably use a orm like Waterline which can abstract away the storage layer.

[akshithg]

@dazzaji another point, when an application requests certain information about the user, do we fetch it from the relevant API or use the information from the file we create? And the user can change information on his profiles after authorization. So how frequently do we pull in new profile data and update the file?

[dazzaji]

Let's discuss and talk through alternatives to fetching from database vs file and frequency of updates (whether updating from database to file or if user amends the file directly and the file is the authoritative record then in theory that should update the database). Once the file is shown to work and can be assessed/digested by a range of stakeholders and potential collaborators we will be in a better position to evaluate the alternatives. So, once we start to add evaluation criteria, this question should be included one way or another and a firmer basis for selecting architecture going forward should be achievable.

[akshithg]

When different Identity services give different values for the same field, how do we determine which value goes into the authoritative source?

[dazzaji]

Can you provide an example of "different Identity services give different values for the same field"? If you mean something like two different email addresses, then the best practice is to append the data from each service as an additional "sub-field" under that field "type". For example, a user may have "david@example.com" as email based on the first service they sign in with and later they may have "dave@there.com" based on second service. The second email would be in an email-2 type field. Make sense?

[dazzaji]

Done!