Notification of IP and antitrust requirements for the drafting group.
Everyone is asked to review the key interoperability questions.
This week, we need to put together an initial (non-IP) briefing for IIW. We’ll be asking for input on the questions from a wider decentralized identity population.
Today’s discussion will be about scope. No other questions were raised prior to starting that discussion.
Mahesh asked if we are primarily working on the method for “how” the rules will be specified, or will we also be specifying a “base set” of rules?
Rob noted that we need to get to something that is useful to the larger community in order for this work to be worthwhile. We need to clearly document this scope.
Trev stated that we can take a stand on the principles behind the rules, while not specifying the specific rules.
Chris brought up the principle page from the white paper. It may be difficult to create a test suite for rules engines.
Tony keeps asking himself what questions could be asked of the person being verified. As a starting point:
What are the credential types?
What is the information in each one?
What can the rules engine ask of those credentials?
We need to be careful not to restrict what can be asked, as the credential types will certainly grow and change.
Chris asked those who already have rules engines if they have user stories that they could share with the group.
Chris suggested that we also look at how the rules engine use cases can be expanded beyond just international travel.
Viola would like us to specify some specific scenarios. International travel is not just airline travel.
Chris suggested three areas to consider for finding scenario(s):
International travel
Back-to-work
Support to disadvantaged group(s)
Rob asked about how this works with international travel where there are other organizations that are already providing rules engine products, which are complex.
Chris brought up verifiable credentials and zero-knowledge proofs in terms of how it relates to rules engines, and the need for us to address these in our outputs.
Rob also brought up the need for identity binding as part of this process.
If you use a rules engine, that means that you have power over granting / managing access.
Chris asserted that if we have a binary-result rules engine, that would allow for the creation of a verifiable credential / proof. This is something that we should explore at IIW.
We start with a verifiable credential, and end with an admit/not-admit decision. The middle part is where the principles are applied. For this, we should provide examples, not necessarily directives. There’s a happy medium.
Our scope is to talk about principles.
Kaliya noted that the blueprint is meant to lead to interoperability. We want to get pretty practical in terms of specifications. How do we get from the world we have today to where we want to get? What are the 30-day goals, 90-day goals, 6-month goals?
Noam suggested that we comment on each of the principles in the white paper through the lens of our drafting group.
Steve brought up that there are three key parts when he thinks about rules engine:
The engine itself
What are the rules the engine processes
What are the inputs and integration points
Interoperability can happen at any of these levels.
Noam asked about how far we go with some of these principles. The example he brought up was a potentially racially discriminatory rule put forward by an aparthied government as part of the “Social Responsibility” principle.
It was suggested that we put each of the principles into the Google Doc to allow the group to discuss.
Savita asked how we should handle the interaction with the Trust Registry in terms of how it interacts with our work.
Viola noted that in current rules engines, the output is “go”, “no go”, or “conditional”.
Jim gave a quick readout of work that is going on in the Trust Registry drafting group.
A conversation regarding the natural follow-on results of this readout.