Federated Registries implementation design

[sukhpreetssekhon]

Trying to understand what are the different elements of a federated registry and how can these be implemented and what are some aspects that we need to consider from a program perspective based on the product design.

Sharing a use case diagram below.

In this diagram above you will observe multiple registries, most of which are source of truth registries for different variables and most of which are dependent on variables in another registry.

Top of mind questions here are:

1. How does this get implemented?
2. How can updates in one registry trigger updates in the other
3. What are some aspects that we need to discover further before getting into the implementation design?

cc - @AnuragSingh55 @surendrasinghs @ChakshuGautam @coolbung @tejash-jl

[sankarshanmukhopadhyay]

2. How can updates in one registry trigger updates in the other

There is likely governance of registry challenge if event trigger-based update chains are implemented. This implies that the transmitting registry is always of the highest assurance and is considered to be canonical. And soon enough, there will be an update storm which keeps triggering the update cycles across all the downstream/dependent registries.

Do you see it as a feasible option that at any point in time, when an action is to be done on R2 it will update/reconcile the details required from R1 before responding? As an example, if the query on R2 is for students of a school with a specific YoB it reconciles with R1 prior to completing the response to the query. The other option could be to have a message queue of sorts which manages the update events for the downstream registry service end-points to reconcile with.

[rahul101001000]

Whoa! Syncing registries beats the purpose of registries. Give control to the user, the user will pull specific profile attributes from other places into the registry they want to.

Mastadon does it decently. So does UHI. None of them enable auto sync between registries.

DigiYatra is another good example.. Aadhaar, vaccine, boarding pass don't sync to update my profile in some central place, I choose to pull them from individual registries and bundle them up and choose to share with the airport.

[surendrasinghs]

Yes, completely agree. Let the users pull updates.

The registries may nudge the users to keep their details up-to-date. Each registry can implement their own data refresh policies. For example, the banks can request for a KYC refresh every year (to all users) whereas the telecom operator may never ask for KYC refresh (after the initial registration KYC).

[surendrasinghs]

Few updates from a small group discussion. Notes here.

1. @sukhpreetssekhon We should also expand the diagram with some more use-cases, for example, Registry type 2 - Student registry could also be spread across multiple registries e.g. I, as a student, may have studied in Kendriya Vidyalaya from Class 1-5, in a govt school from class 6-8, and a private school from class 9-12, where each of the school system had a different registry.

2. Today there was a small group meeting (@coolbung, @tejash-jl, @ChakshuGautam, Anurag, @sukhpreetssekhon , Snehal, and myself). We agreed that we need to discuss and details the following pieces

   1. Registries will always pull data from other registries/source based on user-initiated action or prior consent. Registries will implement policies to nudge users for updating their data (discussed in the earlier comments).
   2. Registry schema that allows and supports fields from other registries with their appropriate resolving methods. We may recommend a normative schema similar to did (decentralized identity) for these fields
   3. Consent artefact, such that each registry stores & cache (from other sources) minimal data it needs to issue VCs and has consent to retrieve data from the source registry when needed.
   4. Resolver (based on DID-Web) so that the data can be retrieved using a specification for web2.0.

@coolbung @ChakshuGautam @tejash-jl please add if anything. This group is maintaining working notes here.
Please comment to give feedback on the same directly in the document.

[AnuragSingh55]

Adding Nitin to this thread +Nitin Kashyap ***@***.***>

…

On Mon, 15 May, 2023, 6:16 pm Surendrasingh Sucharia, < ***@***.***> wrote: Few updates from a small group discussion. Notes here <https://docs.google.com/document/d/1gN6cxZ17ctwRqSRtZvBianXH4cjw0Ok3xttMkYS3984/edit#heading=h.ghrcepn1u3cw> . 1. @sukhpreetssekhon <https://github.com/sukhpreetssekhon> We should also expand the diagram with some more use-cases, for example, Registry type 2 - Student registry could also be spread across multiple registries e.g. I, as a student, may have studied in Kendriya Vidyalaya from Class 1-5, in a govt school from class 6-8, and a private school from class 9-12, where each of the school system had a different registry. 2. Today there was a small group meeting ***@***.*** <https://github.com/coolbung>, @tejash-jl <https://github.com/tejash-jl>, @ChakshuGautam <https://github.com/ChakshuGautam>, Anurag, @sukhpreetssekhon <https://github.com/sukhpreetssekhon> , Snehal, and myself). We agreed that we need to discuss and details the following pieces 1. Registries will always pull data from other registries/source based on user-initiated action or prior consent. Registries will implement policies to nudge users for updating their data (discussed in the earlier comments). 2. Registry schema that allows and supports fields from other registries with their appropriate resolving methods. We may recommend a normative schema similar to *did* (decentralized identity) for these fields 3. Consent artefact, such that each registry stores & cache (from other sources) minimal data it needs to issue VCs and has consent to retrieve data from the source registry when needed. 4. Resolver (based on DID-Web) so that the data can be retrieved using a specification for web2.0. @coolbung <https://github.com/coolbung> @ChakshuGautam <https://github.com/ChakshuGautam> @tejash-jl <https://github.com/tejash-jl> please add if anything. This group is maintaining working notes here <https://docs.google.com/document/d/1gN6cxZ17ctwRqSRtZvBianXH4cjw0Ok3xttMkYS3984/edit#> . *Please comment to give feedback on the same directly in the document.* — Reply to this email directly, view it on GitHub <#673 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZQBYFK3N5LLOXN3CCZ65MTXGIQRFANCNFSM6AAAAAAX5VPA54> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[sukhpreetssekhon]

Few updates from a small group discussion held on 16 May.
(Attendees - @coolbung, @tejash-jl, @surendrasinghs @ChakshuGautam, @AnuragSingh55, @snehal0904 and I)

Common understanding established

1. Key change from RC 1.0 to RC 2.0 - RC will not store entity data in RC 2.0 and will be able to directly generate credentials from the relevant database / registry. Credentials once created will be stored in RC. In RC 1.0 all data for which credentials were to be generated would be copied and stored within RC as entity data.

2. Discussions underway in the RC community for driving the change from RC 1.0 to 2.0 - All the related tickets 317, 318, 219, 320 are linked here for reference.

Action items identified

**1. Open questions about RC 2.0 merge - @ChakshuGautam and @snehal0904 to clarify any open questions about RC2.0 merge from the RC ULP reference solution.

**2. RC 1.0 to 2.0 Consolidation doc - Samagra team to create a document clarifying / consolidating the key changes / enhancements made from RC1.0 to RC2.0 as part of the ULP reference solution as well as what it still doesn't support.

3. Review existing discussions - @surendrasinghs You can review the existing tickets mentioned above and call out any gaps that you observe with respect to the clarity needed for the community to understand the ticket better

4. Evangelize / provide clarity of this change to the RC community - @surendrasinghs You may schedule a RC community call to help the community clearly understand the change and its implications.

5. Open items - @tejash-jl Tickets can be created for any open items with regard to this shift in design from RC 1.0 to 2.0 that have not been discussed so far. The same can then be detailed by @Renuka-S and you before discussing it in a RC community call.

Please share in case I missed any point in the summary above.

cc - @kashyapnitin