Request: selection criteria for identifying parties about aries-rfcs

[llorllale]

@dhh1128 @troyronda

[dhh1128]

@brentzundel and @ken-ebert: Among other things, what @llorllale is asking for here includes a rich and easy way for two parties to talk about attributes of a third: "Can you introduce me to someone who knows you _____ [are a member of the American Academy of Pediatrics; speak Spanish]". I expressed some concerns about personal privacy in third-party interactions like this, but note that in my examples, the request for proof was not about a third party--it was proof about the speaker, but a third party who already knew the same thing. The more dangerous variant would be "can you introduce me to someone who has attribute X ____", which may or may not be in scope here. Note as well that in cases where privacy doesn't matter, both variants would be supremely useful: "Can you introduce me to a self-driving car that's headed downtown?"

Regardless of the subtleties, the reason I'm mentioning both of you on this ticket is that I think the ability to express criteria in this way connects strongly with your work on Schema 2.0. What thinking do you already have on an expressive, powerful language for criteria?

[dhh1128]

@llorllale: I am wondering if we could tweak SGL (Simple Grant Language), or fork it, as a criteria language. Today it only matches on the id and roles properties of people, but making it support arbitrary other criteria would probably be trivial.

Tagging @mcorning as he might also be interested.

[mcorning]

Thanks for including me, @daniel Hardman<mailto:[email protected]>. I am all in on SGL. It's impact may reach far beyond Aries. Rwap

…

________________________________ From: Daniel Hardman <[email protected]> Sent: Friday, August 9, 2019 2:48:00 PM To: hyperledger/aries-rfcs <[email protected]> Cc: Michael Corning <[email protected]>; Mention <[email protected]> Subject: Re: [hyperledger/aries-rfcs] Request: selection criteria for identifying parties (#174) @llorllale<https://github.com/llorllale>: I am wondering if we could tweak SGL (Simple Grant Language)<https://github.com/evernym/sgl>, or fork it, as a criteria language. Today it only matches on the id and roles properties of people, but making it support arbitrary other criteria would probably be trivial. Tagging @mcorning<https://github.com/mcorning> as he might also be interested. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#174?email_source=notifications&email_token=ABYY7LST6T7M4XMLLCPUEE3QDXQZBA5CNFSM4IKXH4MKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD373LWY#issuecomment-520074715>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABYY7LWPUIDL6MY4KIG77NDQDXQZBANCNFSM4IKXH4MA>.

[llorllale]

@dhh1128 @mcorning how do we go about tweaking SGL for these use cases? The criteria language needs to be used in two places:

• The initial requestor needs to describe what he wants
• The Introducer needs to describe the other party to the requestor

[dhh1128]

Reduced to its essence, SGL is just a very simple way to answer this question:

Does this JSON object (or array of objects) satisfy the arbitrary criteria I've written?

It was written with a particular problem in mind, which was to test authorization. However, it could easily be genericized; updating the code to support other properties besides those related to authorization would be quite easy. It's very simple code (maybe 100 lines of JavaScript?), which is part of why it's an attractive answer.

However, I wouldn't go down this road unless/until we do some research about a generic JSON query library (find parts of a JSON tree that match this criteria). If such a library exists, it might be a better alternative. The reason is that the community outside Aries seems to view things that Evernym contributes with suspicion, so SGL incurs some political baggage. (In this case, the language is so simple that I don't think that concern is rational, but I'm just a bit weary about fighting uphill battles).

[llorllale]

@dhh1128 @ken-ebert where can I find docs for Schema 2.0? The name clash with schema.org 2.0 is unfortunate - makes it hard to locate

[llorllale]

@dhh1128 we can lessen the risks of this change by inserting an attachment that contains a network-specific payload (similar to this pattern) in two messages:

introduce/1.0/request:

{
  "@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/introduce/1.0/request",
  "@id": "df3b699d-3aa9-4fd0-bb67-49594da545bd",
  "please_introduce_to": {
    "name": "Carol",
    "description": "The woman who spoke after you at the PTA meeting last night.",
    "expected": true,
    "criteria~attach": {    // new
        "mime-type": "application/json",
        "data": {
            "base64": "<network-specific>"
        }
    }
  },
  "nwise": false,
  "~timing": { "expires_time": "2019-04-23 18:00Z" }
}

didexchange/1.0/invitation:

{
    "@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/didexchange/1.0/invitation",
    "@id": "12345678900987654321",
    "label": "Alice",
    "recipientKeys": ["8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K"],
    "serviceEndpoint": "https://example.com/endpoint",
    "routingKeys": ["8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K"],
    "criteria~attach": {    // new
        "mime-type": "application/json",
        "data": {
            "base64": "<network-specific>"
        }
    }
}

[llorllale]

The addition to didexchange/1.0/invitation is also interesting in that it ratchets up the level of trust of the invitation being received.

[dhh1128]

I think you are onto something good here, George. I agree that expressing criteria in this way is a desirable feature, and in particular, that it would be ideal if the criteria you express in this type of use case uses exactly the same mechanism as criteria expressed in ordinary proof requests.

Here is an insight that I had when discussing this with George over the phone just now, that I want to record in this public thread:

An introduction involves 3 stakeholders. We can therefore think of it as creating or depending upon a 3-way relationship, even though only 2 of the stakeholders (the introducees) actually end up doing DID exchange when we are done. And in that 3-way relationship, selection criteria might need to be expressed about any one of the 3 2-way pairs in the relationship, or any of the 3 individual parties in the relationship. The request for an introduction could say any of the following: Please introduce me to someone who...

• ...is a doctor (matching criteria are tested against credentials of the other introducee, or maybe against informal knowledge that the introducer has; privacy cautions apply here)
• ...has been your friend for over a year (matching criteria are tested against the relationship between introducer and the other introducee)
• ...is the person I met last week (matching criteria tested against the relationship between the two introducees, as embodied in knowledge the introducer has)
• ...is someone who lives near me, speaks my language, and is a plumber (matching criteria tested against knowledge that the introducer has about BOTH of the introduces, AND against one attribute of the other introducee)
• ...knows you are a doctor (matching criteria tested against the other introducee's relationship to the introducer AND against attributes of the introducer)
• ...believes that I am a doctor (matching criteria tested against the other introducee's knowledge of the first introducee AND against attributes of the party seeking an introduction)

...and so forth.

[dhh1128]

I suggest that we change your single criteria~attach object into an array, to let us express as many of these matching criteria as are needed. We might end up with something like this:

introduce/1.0/request:

{
    // (suppressing parts of the message that are not relevant)
    "criteria~attach": [
        {
            "verb": "asserts",
            "criteria": "introducer.name = 'Alice' OR introducer.name = 'Carol'"
        },
        {
            "verb": "asserts",
            "criteria": "their.zip_code = '93075'"
        },
        {
            "verb": "asserts",
            "criteria": "Bob.vocation = 'plumber'"
        },
        {
            "verb": "can-prove",
            "criteria": "introducer.age > 25"
        },
        {
            "verb": "can-prove",
            "criteria": "their.age > 65 AND their.certifications CONTAINS 'MD'"
        },
    ]
}

[dhh1128]

In the example above, I am using an SQL-like syntax to express criteria. Don't get hung up on that. How we express the criteria isn't the point. What matters is the following:

1. We can have as many criteria objects as we like in the attachment array.
2. Each object in the array has a verb that tells how the criteria must be evaluated. The can-prove verb means that evaluation should be rooted in credentials. The asserts verb means the evaluation can be based on self-assertion or other informal knowledge.
3. Each object in the array expresses criteria that are namespaced according to which party in the relationship is being described. Here, I've shown their.* to reference the other introducee, and introducer.* to reference the introducer, and Bob to reference some completely separate party that is none of the parties involved in the introduction.

[dhh1128]

Regarding point 3 in the preceding comment, the ability to namespace criteria according to which party is being described needs to be part of general proof request syntax already. If I am asking for proof from a birth certificate, I already need to be able to say, in effect: Prove to me that... mother.first_name = 'Alice' AND baby.birth_month = 'December'.

[llorllale]

Just realized this was still open from reading the agenda for today's call.

The help-me-discover RFC was submitted for this and we are still in exploration and assessment of this spec.

Will open new issues if/when something comes up.