(#99) Add selection criteria to RFC 0028

[llorllale]

Closes #99

Adds selection criteria to the request message of the Introduce protocol in a generic way as a step towards enabling resource discovery. As a result, two new states were added to the Introduce protocol.

There are two TODOs:

• Can we standardize on a language for the selection criteria? It would be nice if we could define a technical spec for this language.
• How to tag introducee with criteria in the didexchange/invitation message? I'm not certain what the best approach would be, whether via a decorator or by extending the didexchange RFC.

Further notes:

• I've inlined all existing JSON snippets.
• I've replaced the (confusing) state transition table with state diagrams written in PlantUML. This can be reverted if so desired (although I don't have access to the original spreadsheet in google docs). Because of the way I've linked to them, you won't be able to see them when viewing the README in this PR, but they can be seen here:
  • Introducer States
  • Introducee States

Signed-off-by: George Aristy george.aristy@securekey.com

[llorllale]

cc @dhh1128

[dhh1128]

@llorllale Thank you for raising this. It's good stuff.

Some points of feedback:

1. You should be listed as the second author in your PR; this contribution is significant.

2. PlantUML is fine for replacing the state diagrams, and your diagrams are very clean. However, I think we should make them local links. Save a .puml for each diagram, and then also save a PNG or SVG of it, to embed in the README. This will avoid linking out to plantuml.com.

3. What happens if errors occur at a particular stage? Do we start over, or just try again at that stage? The state diagrams should show this.

4. I'm feeling that we need to be careful about how we add credential-based criteria to an introducee descriptor. If we get too ambitious, it could place too much burden on introductions and complicate trust by creating a reliance on the introducer or the introduce protocol that shouldn't be there. It could also turn the introduce protocol into a nefarious way to gather info; agents could ask for an introduction just so they can discover what the introducer knows are the proved attributes of a third party, which threatens cybersecurity and privacy. I want the introduce protocol to offer a reasonable quality of service--best effort to satisfy rough and safe criteria--and then set the expectation that introducees will be evaluating granular, credential-based after they can talk directly.

This doesn't mean I am against criteria, or that I only want to support ones that require human evaluation. I'm just sensing a tension, and I'm thinking about it...

The specific example you give of a network-specific payload for criteria~attach troubles me, because it shows criteria that would undermine the privacy of a driver's license holder and credit score holder by having the introducer reveal something that the potential introducee has not given consent to share. It cannot be the case that the introduce protocol subverts privacy in this way.

Do you have use cases where you need the introduction to be highly precise (please introduce me to exactly the IoT device with this serial number)? Can we list them?

I have raised a PR against your fork (llorllale#1) so you can see where my head is at.

[llorllale]

@dhh1128

I merged your pull request. I also fixed point 2.

3. What happens if errors occur at a particular stage? Do we start over, or just try again at that stage? The state diagrams should show this.

I struggled a bit with this because errors can occur anywhere. I think the only meaningful error state for the Introducer could be between arranging and the end point: the Introducer would report any "error" back to the requestor, such as a rejection, or a generic error (timeout, i/o, etc.).

4. I'm feeling that we need to be careful about how we add credential-based criteria to an introducee descriptor. If we get too ambitious, it could place too much burden on introductions and complicate trust by creating a reliance on the introducer or the introduce protocol that shouldn't be there. It could also turn the introduce protocol into a nefarious way to gather info; agents could ask for an introduction just so they can discover what the introducer knows are the proved attributes of a third party, which threatens cybersecurity and privacy. I want the introduce protocol to offer a reasonable quality of service--best effort to satisfy rough and safe criteria--and then set the expectation that introducees will be evaluating granular, credential-based after they can talk directly.

You bring up two points here (if I'm reading it right):

We should not use the Introduction Protocol to bootstrap trust in a new relationship

Agreed.

An Agent should not reveal the provable attributes of another Agent without the latter's consent.

I failed to make this clear: when an Agent requests an introduction with criteria, they are not (in our use cases!) asking for provable attributes about anyone - they are asking for a third party Agent that has provable attributes about the Introducer. So to follow the network-specific example I wrote, the question to the Introducer is not "can you introduce me to someone who has a driver's license?", but rather "can you introduce me to someone who can prove you have a driver's license?" But I can see perfectly why it can be interpreted just as you did.

Do you have use cases where you need the introduction to be highly precise (please introduce me to exactly the IoT device with this serial number)?

Our use cases are the sharing of provable attributes of a Data Subject by a third party with the former's consent. The request for introduction with criteria would go to the Data Subject, where they would give informed consent (or rejection), and introduce the requestor to the Holder of these attributes (with the Holder's consent).

(we've looked at RFC 0103 but have trouble fitting our use cases into those models without squinting really hard)

[TelegramSam]

Merging held for George and Daniel discussion.

[llorllale]

@dhh1128 I've added a problem_report state to the Introducer's state machine.

Regarding your point about violating a potential introducee's privacy - do you see valid use cases where an Agent can ask another for attributes about a third party? That thought has not been expressed in any of the other "feature" RFCs that I know of.

[dhh1128]

@llorllale This is getting better with each commit. Thanks for continuing to work on this.

I've been silent since your comment last week partly because I'm busy, but also because I'm scratching my head about your use case. It feels very odd to me to ask ask a third party for attributes. I can't wrap my head around it, so I feel stuck. Maybe we need another personal conversation?

[llorllale]

@dhh1128 would an alternative involving a "redirection" of a request-presentation (present-proof RFC) via the Introduce protocol assuage your concerns?

[troyronda]

@dhh1128 So far, there are DIDComm protocols for how Alice can share data and proofs for credentials she is holding in her Agent. But, there are also scenarios where we want to enable Alice to control access to resources held elsewhere (e.g., on a service or even from a device).

When @llorllale "third party", what is meant is a service where Alice has a relationship/connection and that service and Alice has registered her control over a set/scope of resources.

With her control registered:

• Alice should now be able to inform RPs where to locate resources (resource discovery via the User).
• Alice should be enabled to provide RPs with an Authorization Credential to access the service.

With some characteristics such as:

• The RPs and Resource "Services" (RS) should not need a priori relationships - they can establish trust via DIDComm and their own credentials.
• The parties should be able to create an NWise relationship to mitigate against correlation. i.e., They can create a new context when Alice introduces the RP and the RS.
• The RP should be able to describe what they need to Alice (to enable resource discovery). The User (via their User Agent) decides how to fulfill this request.
• The "Authorization Credential" mechanism also fulfills the role of a "Consent Receipt".

The above does introduce some overlap with the goals of UMA, but doing so via DIDComm.

[dhh1128]

@llorllale Yes, a redirection feels much better to me. It would match the pattern described here.

@troyronda Thank you. The general pattern you describe makes a lot of sense to me, and it is more or less the way I was imagining agents and hubs would collaborate: Alice's agent introduces Bob and her hub to one another, and then lets the two of them talk directly. It also matches the way CDNs work on the web today. However, I wouldn't use the term "RP" or "Relying Party" for a party who wants resources; that term has a very specific meaning with respect to credentials. I don't think credentials are best modeled as resources. That's a bigger discussion than this ticket, though.

The main thing I want to do is get the introduce protocol right-sized--sophisticated enough to handle introductions, but not bogged down with stuff that deserves a new protocol in its own right. Maybe some of that balancing act can only happen as we try to implement, and we learn what the code looks like and whether we like it.

[dhh1128]

@llorllale I want to get this merged instead of leaving it in limbo. But I do think we might be putting too much into the introduction protocol, instead of decomposing it into a subprotocol for identifying introducees that match criteria, followed by a very simple introduce protocol that matches common human uses and that could serve as the second half of a sophisticated, automated introduction like the one you need.

So: what is your vote? Shall we merge this now, and work on decomposition after--probably generating a new RFC for that new subprotocol? Or do you want to work with me now to revise?

[llorllale]

@dhh1128 I'm OK with merging this now and working on that new subprotocol.

This RFC is still very rough around the edges and has a couple of big TODOs, but that's ok since it's still in PROPOSAL, right?

[swcurran]

My $0.02 is that the selection criteria and related consent work is a separate protocol that could be used for different things and so is over the top for introduction. IMHO The introduction protocol should be about introductions amongst known entities. Determining why and discovering who is needed for a specific introduction ought to be a separate protocol.

[llorllale]

I opened #174 for the subprotocol.

[dhh1128]

Update: this is still being discussed in issue #174

[swcurran]

I think the RFC needs work in two areas.

• The original introduction section that says "it's simple, but handles many cases" is no longer really true given the newly proposed text of the RFC. The complexity of the use cases to be handled are significantly more complex than is implied in the introduction and so the introduction should be suitably adjusted.

• While I sort of get that the use case implied in the "request" message, one or more of those use cases that are addressed by that message should be added to the RFC. It's really not clear to me what this is for and how it is part of the same RFC that Daniel originally raised.

How about making this PR and RFC the subject of an Aries WG call and going over it for the community?

[swcurran]

Another clarification that would help me, but it goes back to the original submission from @dhh1128.

An introducer sends a proposal to an introducee, and the introducee sends back a response with an invitation. Shouldn't the introducer use another message to send the invitation to the other introducee? It's the two introducee's that are trying to connect to one another, right?

Here's how I understand it's supposed to work (in life, at least):

• Alice wants to introduce Bob and Carol, sends a proposal message to each.
• Bob sends a response message back to Alice containing an invite for Carol.
• The invite is intended for Carol to enable establishing a connection with Bob, so Alice sends the invite to Carol who responds with a connection/request-connection response.
  • This is not covered in the original protocol
  • Related question: What happens if both Bob and Carol send an invitation to Alice?

Where did I get lost?

[llorllale]

The addition of RFC0214 and RFC0217 have rendered this PR unworkable. I'll be opening a new PR for a minor tweak to this protocol to account for these two new RFCs.