You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Aries Frameworks are trying to converge on the elimination of unqualified peer DIDs, and their replacement with support for various forms of did:peer DIDs. In this context "peer DIDs" means DIDs used for DIDComm messaging, exchanged by agents when they establish a DIDComm connection (via "Connections" or OOB/DID Exchange protocols). "did:peer" are DIDs defined by according to the did:peer specification.
Unqualified DIDs go back to the early days of Aries and the "did:sov" method of defining peer DIDs. An agent, sends to the other agent a "DID" without a did:XXXX prefix (hence, unqualified) and a DID Doc. In order to eliminate that, we want to go through a community coordinated update (described in RFC 0793 unqualified DID transition) that begins with all Aries frameworks sending out unqualified DIDs, but accepting both unqualified and various qualified did:peer DIDs (notably, did:peer:1, did:peer:2 and did:peer:4) and later switching to sending out only qualified DIDs. Currently, all of the Aries Frameworks are being updated up to both accept and send out all types of peer DIDs.
"Accepting" in this case means properly handling a peer DID of a given type sent to it in initiating a connection, and responding by using that DID in completing the connection establishment. So, if the invitation or request are the first messages in establishing a connection, and they contain a given DID type, the recipient of the invitation or request should respond using the same peer DID type.
The testing we would like is:
Have the test agents running.
Have Acme configured to initiate a connection with a specified peer DID type (unqualified, did:peer:1, did:peer:2, did:peer:4)
We may need to use the "restart agent with new settings in the middle of a run" approach
Have Acme connect to Bob, (and perhaps Faber and Mallory)
Thought is that by doing three connections, we can have a different test agent (ACA-Py, AFJ, Aries VCX) for each, so fewer test runs, but that may or may not be a good idea.
Have Acme check that Bob, Faber and Mallory all respond with whatever type of peer DID Acme used.
This task is to create the set of tests, and define how the tests will get run -- e.g. how to on the fly change Acme to initiate connections with the required type of peer DID.
The text was updated successfully, but these errors were encountered:
The Aries Frameworks are trying to converge on the elimination of unqualified peer DIDs, and their replacement with support for various forms of did:peer DIDs. In this context "peer DIDs" means DIDs used for DIDComm messaging, exchanged by agents when they establish a DIDComm connection (via "Connections" or OOB/DID Exchange protocols). "did:peer" are DIDs defined by according to the did:peer specification.
Unqualified DIDs go back to the early days of Aries and the "did:sov" method of defining peer DIDs. An agent, sends to the other agent a "DID" without a
did:XXXX
prefix (hence, unqualified) and a DID Doc. In order to eliminate that, we want to go through a community coordinated update (described in RFC 0793 unqualified DID transition) that begins with all Aries frameworks sending out unqualified DIDs, but accepting both unqualified and various qualifieddid:peer
DIDs (notably,did:peer:1
,did:peer:2
anddid:peer:4
) and later switching to sending out only qualified DIDs. Currently, all of the Aries Frameworks are being updated up to both accept and send out all types of peer DIDs."Accepting" in this case means properly handling a peer DID of a given type sent to it in initiating a connection, and responding by using that DID in completing the connection establishment. So, if the invitation or request are the first messages in establishing a connection, and they contain a given DID type, the recipient of the invitation or request should respond using the same peer DID type.
The testing we would like is:
did:peer:1
,did:peer:2
,did:peer:4
)This task is to create the set of tests, and define how the tests will get run -- e.g. how to on the fly change Acme to initiate connections with the required type of peer DID.
The text was updated successfully, but these errors were encountered: