Pushing Proofs from Agents for Updated Information


#1

Has there been any discussion about agents using rules to push proofs to interested parties? This came up in some use cases we have around using claims and proofs as a means of integrating systems via the individual.

For example, let’s suppose I have a claim about my mailing address. Could I have my agent automatically provide an updated proof about that address to registered parties whenever I update my address? For example, if BYU is using an agent-based, student-controlled system as the means of storing student information, how do we know when the student has updated their address?

Or would it be better to raise events when the address changes and have parties who’ve registered for that event request a proof? In this example, a mailing_address_change event would be raised to registered parties and they’d then know to request a new address proof.

The nice thing about proofs is they’re linked to a public schema that says what the fields mean. Any kind of push mechanism, whether built into the proof system via agent rules or done out of band, should link change notifications (events) to the schema fields.


#2

Phil, I totally agree this should be supported. One question:

I’m not sure I followed “should like change notification (events) to the schema fields”. Could you updack that a bit more?


#3

Stupid autocorrent. Should read:

“Any kind of push mechanism, whether built into the proof system via agent rules or done out of band, should link change notifications (events) to the schema fields.”


#4

We have the notion of a “proof offer”, which allows a prover to tell a verifier that they can provide an up to date proof of something (such as mailing address) if they want it, and the verifier can respond with a proof request if they do. The prover’s agent should let the identity owner express preferences and policies for who gets notified about what, with sensible defaults based on past behaviour. If a verifier requires an up to date address at a particular point in time, they should initiate a proof request at that time.


#5

Very good. So, an agent could have rules that automatically make proof offers to some verifiers based on whatever criteria the identity owner wanted to stipulate.


#6

Yes, exactly. Jason also clarified today that, if a connection is already in place, the publishing agent does not have to send a proof offer to the relying party that in turn elicits a proof request right back. The agent can just send the new proof. It’s that classic dilemma between sending a notification of new data or just sending the new data. Both are supported.


#7

When you say “connection” what do you mean?


#8

A Sovrin connection is just a more abstract version of an XDI link contract (for newcomers to that concept, Phil is a member of the OASIS XDI Technical Committee where it was developed, so that’s why I’m using this metaphor).

Specifically, in Sovrin agent architecture, a connection is the simplest form of a link contract where the two Identity Owners have each generated pairwise DIDs, pairwise key pairs, and pairwise agent endpoints for communicating with each other. Once that’s done, they have a “channel” (another overloaded word, but one I know Phil uses in pico architecture) for encrypted communications with each other.

All you need to do is start to add some metadata to the pairwise DIDs to represent the data that one or both parties have agreed to share—and them the permissions they’ve associated with that data—and then even tie it to a trust framework—and voila, you have a link contract.

Make sense?


#9

I’ve posted these before, but just for reference, these two demos show XDI link contracts in action (including pushing updated information):

Overview of some XDI use cases (shown at MyData2016 and IIW#23):
Vimeo Link

Passenger Name Record:
Vimeo Link

Can’t wait to hook up XDI link contracts with Sovrin DIDs!


#10

Hey @Drummond, would you mind explaining what does exactly mean to “tie” the connection to a “trust framework” in this context?


#11

Carlos, by “tie” I meant that something as simple as a link, shared between two pairwise DIDs that establish the connection, that contains a reference to the DID (and version) of the trust framework under which the two Identity Owners are agreeing to share data.

In JSON pseudocode, this would look something like:

{
  "link": ["alice-DID", "bob-DID"],
  "framework": "trust-framework-DID"
}

The question is what this link structure looks like in practice, because both Alice and Bob need to share a copy of it. As Markus points out, XDI has one way of doing it based on the XDI semantic graph model. The question the Sovrin community will need to work out is what will be the interoperable format that everyone needs to share.


#12

That’s awesome. I didn’t know a trust framework would have its own “identity” on the ledger. That, of course, makes complete sense. :slight_smile:


#13

On final note: the one trust framework that Sovrin Identity Owners do not need a shared link to is the Sovrin Trust Framework (about to enter its second Public Review Draft) because it’s required for all Sovrin DIDs.


#14

@james - i’d love to hear a bit more about that. can you wlak me through that? say I subscribed to Rolling Stone, then I moved, etc…

@carlos, @drummond - the concept of a reference to a trust framework seems to me a reference to the “locus of adjudication” and perhaps a reference to a “corpus of law” - is that the correct understanding of the “pointer to a trust framework?” or did I fundamentally miss something (huge possible yes there! :wink:

@peacekeeper - i very much like XDI, but i find it like the Apple Newton… so i find myself dealing with scaled back minimal featured versions of the same that are in earnest deployment - Apollo/GraphQL systems, for example. In terms of “push notifications” in such a framework, could you help me present the XDI solution?


#15

Eric, I think you have it right—as long as “locus of adjudication” does not mean “specific jurisdiction”. While a trust framework MAY be written for one legal jurisdiction, many of them are written to work across multiple legal jurisdictions. The core idea is flexibility of legal context—any two agents could connect for any purpose and agree to any trust framework relevant to that connection.