OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xdi] XDI TC Unofficial Telecon Notes: Thursday 2018-07-05


Markus, thanks much for an excellent notes on the meeting. I think Phil andÂJoseph will be fascinated by this, so we may want to revisit the topic in our next call that they both can attend.

Going offline on myÂvacation now.

=DrummondÂÂ

On Fri, Jul 6, 2018 at 4:50 PM, Markus Sabadello <markus.sabadello@xdi.org> wrote:

XDI TC Notes


Following are the notes of the unofficial telecon of the XDI TC held on:

Date: Thursday, 5 July 2018 USA
Time: 1:00PM - 2:00PM Pacific Time (20:00-21:00 UTC)


The TC operates under a standing rule approved 17 July 2008 under which the TC does not hold regular official meetings and conducts all business by electronic ballot only. Unofficial weekly meetings are held to enable discussion among members but no business is conducted nor actions taken.

ATTENDING

Markus Sabadello
Drummond Reed

REGRETS

Phil Windley

NOTES

Credentials/Proofs and XDI

We discussed how the concepts of Verifiable Credentials and Proofs can be modeled in XDI. For Rebooting-the-Web-of-Trust #4, Markus wrote a topic paper related to this subject.


Markus began with a simple example of the use of $rep arcs, unrelated to the topic of credentials/proofs:


Example Graph:


=!:did:sov:1[<#email>]<@~1>/&/âmarkus.sabadello@gmail.comâ

=!:did:sov:1[<#email>]<@~2>/&/âmarkus@danubetech.comâ

=!:did:sov:1[<#email>]<@~3>/&/âmarkus.sabadello@sovrin.orgâ


=!:did:sov:1<#home><#email>/$rep/=markus[<#email>]<@~1>

=!:did:sov:1<#work><#email>/$rep/=markus[<#email>]<@~2>


=!:did:sov:1<#email>/$rep/=markus<#home><#email>


Example Message:

ÂÂÂ ÂÂÂ

=!:did:sov:55[$msg]*!:uuid:1234/$from/(=!:did:sov:55)

=!:did:sov:55[$msg]*!:uuid:1234/$to/(=!:did:sov:1)

=!:did:sov:55[$msg]*!:uuid:1234/$contract/(=!:did:sov:1/=!:did:sov:55)$contract

=!:did:sov:55[$msg]*!:uuid:1234$do/$get/=!:did:sov:1<#email>


Example Response:

ÂÂÂ

=!:did:sov:1<#email>/&/âmarkus.sabadello@gmail.comâ


The point of this simple example is that the response contains XDI statements that are not actually present in the target graph - they are instead dynamically constructed based on the incoming message and the $rep arcs found in the target graph.


Next, Markus proposed how a typical credential in a wallet (as used by the Hyperledger Indy project) could be modeled in XDI (with several simplifications):


Example Credential:


*!:uuid:xxx/$is#/#wallet

(*!:uuid:xxx)#testschema/#issuer/+!:did:sov:8

(*!:uuid:xxx)#testschema<#sex>/&/âmaleâ

(*!:uuid:xxx)#testschema<#name>/&/âAlexâ

(*!:uuid:xxx)#testschema<#age>/&/28

(*!:uuid:xxx)#testschema<#height>/&/175

(*!:uuid:xxx)#testschema<$sig><#m_2>/&/â...â

(*!:uuid:xxx)#testschema<$sig><#a>/&/â...â

(*!:uuid:xxx)#testschema<$sig><#e>/&/â...â

(*!:uuid:xxx)#testschema<$sig><#v>/&/â...â


Example Credential (different approach using an inner root that represents the relationship between the issuer and the identity owner):


*!:uuid:xxx/$is#/#wallet

(*!:uuid:xxx)(+!:did:sov:8/*!:uuid:xxx)#testschema<#sex>/&/âmaleâ

(*!:uuid:xxx)(+!:did:sov:8/*!:uuid:xxx)#testschema<#name>/&/âAlexâ

(*!:uuid:xxx)(+!:did:sov:8/*!:uuid:xxx)#testschema<#age>/&/28

(*!:uuid:xxx)(+!:did:sov:8/*!:uuid:xxx)#testschema<#height>/&/175

(*!:uuid:xxx)(+!:did:sov:8/*!:uuid:xxx)#testschema<$sig><#m_2>/&/â..â

(*!:uuid:xxx)(+!:did:sov:8/*!:uuid:xxx)#testschema<$sig><#a>/&/â...â

(*!:uuid:xxx)(+!:did:sov:8/*!:uuid:xxx)#testschema<$sig><#e>/&/â...â

(*!:uuid:xxx)(+!:did:sov:8/*!:uuid:xxx)#testschema<$sig><#v>/&/â...â


Example Message (proof request; requesting one of the attributes):


=!:did:sov:55[$msg]*!:uuid:1234/$from/(=!:did:sov:55)

=!:did:sov:55[$msg]*!:uuid:1234/$to/(=!:did:sov:1)

=!:did:sov:55[$msg]*!:uuid:1234/$contract/(=!:did:sov:1/=!:did:sov:55)$contract

=!:did:sov:55[$msg]*!:uuid:1234$do/$get/=!:did:sov:1<#name>


In order to properly respond to this message with a proof based on the credential above (as used by Hyperledger Indy), Markus felt that two constructs need to be present in the target graph:


  1. One or more $rep arcs that connect DIDs to the credentials in the wallet (to model pairwise-pseudonymous DIDs):


=!:did:sov:1/$rep/*!:uuid:xxx

=!:did:sov:2/$rep/*!:uuid:xxx

=!:did:sov:3/$rep/*!:uuid:xxx


  1. A new special predicate called $proof (or $indy$proof, etc.) that points to the credential in the wallet:


*!:uuid:xxx<#name>/$indy$proof/(*!:uuid:xxx)(+!:did:sov:8/*!:uuid:xxx)*!:uuid:xxx#testschema<#name>


In a similar manner to $rep, the $indy$proof arc would also trigger special behavior in an XDI agent; in this case it would dynamically construct and return a proof based on the credential that is the target of this arc (using Hyperledger Indy):


=!:did:sov:1<#name>/&/âAlexâ

=!:did:sov:1<#name><$indy><$proof><#a_prime>/&/â...â

=!:did:sov:1<#name><$indy><$proof><#e>/&/â...â

=!:did:sov:1<#name><$indy><$proof><#v>/&/â...â

=!:did:sov:1<#name><$indy><$proof><#m>/&/â...â


Markus felt that such special processing behavior associated with certain relational arcs ($indy$proof) could be added to an XDI agent in the form of plugins, similar to how XDI connectors can add special processing behavior to certain XDI contexts (e.g. XDI Facebook connector).


Drummond expressed some reservations about this approach of special relational arcs. He argued that $rep provides functionality that is fundamental to the graph model itself, and that this concept should not be generalized / broadened to more complex processing instructions.


Instead, Drummond argued, this same functionality could be achieved in the same way as traditional XDI connectors work which are triggered by certain contextual arcs, not relational arcs. E.g. an <$indy><$proof> context could trigger an XDI connector that invokes special behavior (constructing a proof using Hyperledger Indy):


Example Message (proof request; requesting one of the attributes plus a proof):


=!:did:sov:55[$msg]*!:uuid:1234/$from/(=!:did:sov:55)

=!:did:sov:55[$msg]*!:uuid:1234/$to/(=!:did:sov:1)

=!:did:sov:55[$msg]*!:uuid:1234/$contract/(=!:did:sov:1/=!:did:sov:55)$contract

=!:did:sov:55[$msg]*!:uuid:1234$do/$get/=!:did:sov:1<#name>

=!:did:sov:55[$msg]*!:uuid:1234$do/$get/=!:did:sov:1<#name><$indy><$proof>


Example Response:


=!:did:sov:1<#name>/&/âAlexâ

=!:did:sov:1<#name><$indy><$proof><#a_prime>/&/â...â

=!:did:sov:1<#name><$indy><$proof><#e>/&/â...â

=!:did:sov:1<#name><$indy><$proof><#v>/&/â...â

=!:did:sov:1<#name><$indy><$proof><#m>/&/â...â


Markus published these examples also in the form of a few slides:


https://www.oasis-open.org/committees/document.php?document_id=63369&wg_abbrev=xdi

Overlay Graphs

Markus shared an additional thought on what he called "overlay graphs". This is a mechanism that can make the result of an XDI message depend on the XDI link contract that is being used. For example, given the following target graph:


=!:did:sov:1[<#email>]<@~1>/&/âmarkus.sabadello@gmail.comâ

=!:did:sov:1[<#email>]<@~2>/&/âmarkus@danubetech.comâ

=!:did:sov:1[<#email>]<@~3>/&/âmarkus.sabadello@sovrin.orgâ


=!:did:sov:1<#home><#email>/$rep/=markus[<#email>]<@~1>

=!:did:sov:1<#work><#email>/$rep/=markus[<#email>]<@~2>


Two different XDI link contracts could be formulated:


(=!:did:sov:1/=!:did:sov:2)$contract$do/$get/=!:did:sov:1<#email>

(=!:did:sov:1/=!:did:sov:2)($contract/$overlay)=!:did:sov:1<#email>/$rep/=!:did:sov:1<#home><#email>


(=!:did:sov:1/=!:did:sov:3)$contract$do/$get/=!:did:sov:1<#email>

(=!:did:sov:1/=!:did:sov:3)($contract/$overlay)=!:did:sov:1<#email>/$rep/=!:did:sov:1<#work><#email>


These link contracts contain an $overlay inner root, which contains an "overlay graph" that is temporarily added to the target graph only for the duration of execution of a single message. In the above examples, XDI messages to retrieve an <#email> attribute would return different results depending on which link contract is used, because each link contract adds a different overlay $rep arc:


Example Message and Result 1:


=!:did:sov:2[$msg]*!:uuid:1234$do/$get/=!:did:sov:1<#email>

=!:did:sov:2[$msg]*!:uuid:1234/$contract/(=!:did:sov:1/=!:did:sov:2)$contract


â =!:did:sov:1<#email>/&/âmarkus.sabadello@gmail.comâ


Example Message and Result 2:


=!:did:sov:3[$msg]*!:uuid:1234$do/$get/=!:did:sov:1<#email>

=!:did:sov:3[$msg]*!:uuid:1234/$contract/(=!:did:sov:1/=!:did:sov:3)$contract


â =!:did:sov:1<#email>/&/âmarkus.sabadello@gmail.comâ


Markus believes this functionality can be useful for many use cases; for example, depending on who is sending a message, different proofs based on credentials from different issuers could be returned. Overlay graphs can also be combined with push link contracts, e.g. depending on the identity of the sender of a message, policies could be expressed that forward messages to different target peers.

NEXT REGULAR CALL

The next call will be next week at the usual time (Thursday 1PM PT). The link where agenda items can be posted for the next meeting is: https://docs.google.com/document/d/19oDl0lbb56Grehx2a5flZnhrgnua5l8cVvC_dJ8fTXk/edit?usp=sharing







[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]