Closed tdiesler closed 1 year ago
@TimoGlastra says ... https://discord.com/channels/905194001349627914/1066043270590894200
I think the verification we do in AFJ is to check both. So we check that the did document contains the key that is used to send the did exchange response. In addition if the key used is different than the key in the oob invitation, we require that the attachment is also signed by the invitation key. This is important so you know you're interacting with the did from the invitation)
Thanks
I looked at this more closely - here is what I found ...
When AcaPy sends a Request after receiving an Out-of-Band Invitation, it signs the attached Did Document with the key contained in that Document.
Specifically, it signs the Did Document with did:key:z6MkgnRbNmHJq8YGdtzxUxgqPkqAZ3qRWWFbntsST6D9CykA
from jws.header.kid
, which is the did:key representation of did:sov:5GzbVeQgVwc48ZcLzUkRdP
2023-01-30 09:49:55,947 INFO [main] o.n.d.p.RFC0434OutOfBandProtocol [RFC0434OutOfBandProtocol.kt:91] -- Invitee (Faber) received Invitation: {
"@id":"e5e12f21-98d1-4e96-b0b2-5a633a1e325c",
"@type":"https://didcomm.org/out-of-band/1.1/invitation",
"label":"Alice invites Faber",
"accept":[
"didcomm/v2"
],
"handshake_protocols":[
"https://didcomm.org/didexchange/1.0"
],
"services":[
{
"id":"#inline",
"type":"did-communication",
"recipientKeys":[
"did:key:z6MknrV2etMBZJ87sUdgDS8xoBx5wt4ZasNqg8GVfUyit5JW"
],
"serviceEndpoint":"http://192.168.0.10:8130"
}
],
"state":"initial"
}
2023-01-30 09:49:56,392 INFO [XNIO-1 task-1] o.n.d.p.RFC0019EncryptionEnvelope [RFC0019EncryptionEnvelope.kt:135] -- Recipient verkey: 9QDz4e6kDkdekynyXsB7x6Q68JniAz8Uz7MZqD1hxrX8
2023-01-30 09:49:56,393 INFO [XNIO-1 task-1] o.n.d.p.RFC0019EncryptionEnvelope [RFC0019EncryptionEnvelope.kt:146] -- Sender verkey: 3LAYnX2sVb3oXQAFoPizYfHAjUZa6d1F6sxWcpF8Hkxn
2023-01-30 09:49:56,395 INFO [XNIO-1 task-1] o.n.d.p.RFC0019EncryptionEnvelope [RFC0019EncryptionEnvelope.kt:171] -- Unpacked Envelope: {
"@type": "https://didcomm.org/didexchange/1.0/request",
"@id": "195c50e9-cdf9-433f-910d-676b7a9029ca",
"~thread": {
"thid": "195c50e9-cdf9-433f-910d-676b7a9029ca",
"pthid": "e5e12f21-98d1-4e96-b0b2-5a633a1e325c"
},
"did": "5GzbVeQgVwc48ZcLzUkRdP",
"label": "Aries Cloud Agent",
"did_doc~attach": {
"@id": "96a9b48a-4b9c-4694-9952-c32e29546a2a",
"mime-type": "application/json",
"data": {
"base64": "eyJAY29udGV4dCI6ICJodHRwczovL3czaWQub3JnL2RpZC92MSIsICJpZCI6ICJkaWQ6c292OjVHemJWZVFnVndjNDhaY0x6VWtSZFAiLCAicHVibGljS2V5IjogW3siaWQiOiAiZGlkOnNvdjo1R3piVmVRZ1Z3YzQ4WmNMelVrUmRQIzEiLCAidHlwZSI6ICJFZDI1NTE5VmVyaWZpY2F0aW9uS2V5MjAxOCIsICJjb250cm9sbGVyIjogImRpZDpzb3Y6NUd6YlZlUWdWd2M0OFpjTHpVa1JkUCIsICJwdWJsaWNLZXlCYXNlNTgiOiAiM0xBWW5YMnNWYjNvWFFBRm9QaXpZZkhBalVaYTZkMUY2c3hXY3BGOEhreG4ifV0sICJhdXRoZW50aWNhdGlvbiI6IFt7InR5cGUiOiAiRWQyNTUxOVNpZ25hdHVyZUF1dGhlbnRpY2F0aW9uMjAxOCIsICJwdWJsaWNLZXkiOiAiZGlkOnNvdjo1R3piVmVRZ1Z3YzQ4WmNMelVrUmRQIzEifV0sICJzZXJ2aWNlIjogW3siaWQiOiAiZGlkOnNvdjo1R3piVmVRZ1Z3YzQ4WmNMelVrUmRQO2luZHkiLCAidHlwZSI6ICJJbmR5QWdlbnQiLCAicHJpb3JpdHkiOiAwLCAicmVjaXBpZW50S2V5cyI6IFsiM0xBWW5YMnNWYjNvWFFBRm9QaXpZZkhBalVaYTZkMUY2c3hXY3BGOEhreG4iXSwgInNlcnZpY2VFbmRwb2ludCI6ICJodHRwOi8vMTkyLjE2OC4wLjEwOjgwMzAifV19",
"jws": {
"header": {
"kid": "did:key:z6MkgnRbNmHJq8YGdtzxUxgqPkqAZ3qRWWFbntsST6D9CykA"
},
"protected": "eyJhbGciOiAiRWREU0EiLCAia2lkIjogImRpZDprZXk6ejZNa2duUmJObUhKcThZR2R0enhVeGdxUGtxQVozcVJXV0ZibnRzU1Q2RDlDeWtBIiwgImp3ayI6IHsia3R5IjogIk9LUCIsICJjcnYiOiAiRWQyNTUxOSIsICJ4IjogIklxQTBoLVJEQTgxaWxuS0xuNnlaNWd5VU44RlRCODlHVlhRMFlTRU5ocDgiLCAia2lkIjogImRpZDprZXk6ejZNa2duUmJObUhKcThZR2R0enhVeGdxUGtxQVozcVJXV0ZibnRzU1Q2RDlDeWtBIn19",
"signature": "RQzb5f1ds-Tv0tMe4meF7dM6iY2URpFeofshFRrVza6t8_6WJH6bTR2HtXismEpy2Ry2YEGm2Vu73Pv_dv-wAA"
}
}
}
}
2023-01-30 09:49:56,398 INFO [XNIO-1 task-1] o.n.d.p.RFC0023DidExchangeProtocol [RFC0023DidExchangeProtocol.kt:193] -- Responder (Alice) received DidEx Request
2023-01-30 09:49:56,402 INFO [XNIO-1 task-1] o.n.d.s.DidDocumentService [DidDocumentService.kt:133] -- Extracted Did Document: {
"@context": "https://w3id.org/did/v1",
"id": "did:sov:5GzbVeQgVwc48ZcLzUkRdP",
"publicKey": [
{
"id": "did:sov:5GzbVeQgVwc48ZcLzUkRdP#1",
"type": "Ed25519VerificationKey2018",
"controller": "did:sov:5GzbVeQgVwc48ZcLzUkRdP",
"publicKeyBase58": "3LAYnX2sVb3oXQAFoPizYfHAjUZa6d1F6sxWcpF8Hkxn"
}
],
"authentication": [
{
"type": "Ed25519SignatureAuthentication2018",
"publicKey": "did:sov:5GzbVeQgVwc48ZcLzUkRdP#1"
}
],
"service": [
{
"id": "did:sov:5GzbVeQgVwc48ZcLzUkRdP;indy",
"type": "IndyAgent",
"priority": 0,
"recipientKeys": [
"3LAYnX2sVb3oXQAFoPizYfHAjUZa6d1F6sxWcpF8Hkxn"
],
"serviceEndpoint": "http://192.168.0.10:8030"
}
]
}
When AcaPy sends a DidEx Response as reply of a DidEx Request, it signs the attached Did Document with the invitationKey, instead of the key contained in that Document
Specifically, it signs the Did Document with did:key:z6MkqopNJzgVesySmHK3YthpNvW4bWAKmcTW6kR1VoADjqn3
from jws.header.kid
, which corresponds to invitation.services[0].recipientKeys[0]
2023-01-30 10:17:18,631 INFO [main] o.n.d.p.RFC0434OutOfBandProtocol [RFC0434OutOfBandProtocol.kt:69] -- Inviter (Faber) created Invitation: {
"@id": "44a79b7c-b900-4f58-be10-7f85c5524bc0",
"@type": "https://didcomm.org/out-of-band/1.1/invitation",
"label": "Faber invites Alice",
"accept": [
"didcomm/v2"
],
"handshake_protocols": [
"https://didcomm.org/didexchange/1.0"
],
"services": [
{
"id": "#inline",
"type": "did-communication",
"recipientKeys": [
"did:key:z6MkqopNJzgVesySmHK3YthpNvW4bWAKmcTW6kR1VoADjqn3"
],
"serviceEndpoint": "http://192.168.0.10:8030"
}
],
"state": "initial"
}
2023-01-30 10:17:18,673 INFO [DidEx-0] o.n.d.p.RFC0023DidExchangeProtocol [RFC0023DidExchangeProtocol.kt:174] -- Requester (Alice) sends DidEx Request: {
"@type":"https://didcomm.org/didexchange/1.0/request",
"@id":"7f79736c-818a-4c72-a2b5-5690593ee7dc",
"~thread":{
"thid":"7f79736c-818a-4c72-a2b5-5690593ee7dc",
"pthid":"44a79b7c-b900-4f58-be10-7f85c5524bc0"
},
"did":"9mknvxgt71rjecbd9qS6Zk",
"label":"Invitee Alice",
"did_doc~attach":{
"@id":"adfa9e83-17d1-4b0f-881e-65c8f88320d9",
"mime-type":"application/json",
"data":{
"base64":"eyJAY29udGV4dCI6Imh0dHBzOi8vdzNpZC5vcmcvZGlkL3YxIiwiaWQiOiJkaWQ6c292Ojlta252eGd0NzFyamVjYmQ5cVM2WmsiLCJwdWJsaWNLZXkiOlt7ImlkIjoiZGlkOnNvdjo5bWtudnhndDcxcmplY2JkOXFTNlprIzEiLCJ0eXBlIjoiRWQyNTUxOVZlcmlmaWNhdGlvbktleTIwMTgiLCJjb250cm9sbGVyIjoiZGlkOnNvdjo5bWtudnhndDcxcmplY2JkOXFTNlprIiwicHVibGljS2V5QmFzZTU4IjoiNW5Ia1VUQ0xZUjVheTQyYlZyNEE0NmRINjVrZ1h6VHg4endoWGtLVGhvMUYifV0sImF1dGhlbnRpY2F0aW9uIjpbeyJ0eXBlIjoiRWQyNTUxOVNpZ25hdHVyZUF1dGhlbnRpY2F0aW9uMjAxOCIsInB1YmxpY0tleSI6ImRpZDpzb3Y6OW1rbnZ4Z3Q3MXJqZWNiZDlxUzZaayMxIn1dLCJzZXJ2aWNlIjpbeyJpZCI6ImRpZDpzb3Y6OW1rbnZ4Z3Q3MXJqZWNiZDlxUzZaaztzcnYiLCJ0eXBlIjoiTmVzc3VzQWdlbnQiLCJwcmlvcml0eSI6MCwicmVjaXBpZW50S2V5cyI6WyI1bkhrVVRDTFlSNWF5NDJiVnI0QTQ2ZEg2NWtnWHpUeDh6d2hYa0tUaG8xRiJdLCJzZXJ2aWNlRW5kcG9pbnQiOiJodHRwOi8vMTkyLjE2OC4wLjEwOjgxMzAifV19",
"jws":{
"header":{
"kid":"did:key:z6MkjEYo4hSmsxa45YsJBR1zuCBGuf2XwsiJq1rdN2HUd1nd"
},
"protected":"eyJhbGciOiJFZERTQSIsImtpZCI6ImRpZDprZXk6ejZNa2pFWW80aFNtc3hhNDVZc0pCUjF6dUNCR3VmMlh3c2lKcTFyZE4ySFVkMW5kIiwiandrIjp7Imt0eSI6Ik9LUCIsImNydiI6IkVkMjU1MTkiLCJ4IjoiUndqU3FDNUc1d2ZXX3JyYkRSVVNCNWhHMXI4TW05MTRYWm95S1c2d28yWSIsImtpZCI6ImRpZDprZXk6ejZNa2pFWW80aFNtc3hhNDVZc0pCUjF6dUNCR3VmMlh3c2lKcTFyZE4ySFVkMW5kIn19",
"signature":"kMnjG7WtXsX4NqPPK4kqIVQ1qJfzprDeruJe9B7OW1QOEzt_bUIlhrS6T_CFgZHcvVMnCv-p1w6U26Mz-evMAw"
}
}
}
}
2023-01-30 10:17:19,260 INFO [XNIO-1 task-1] o.n.d.p.RFC0019EncryptionEnvelope [RFC0019EncryptionEnvelope.kt:171] -- Unpacked Envelope: {
"@type": "https://didcomm.org/didexchange/1.0/response",
"@id": "5d7b609b-d93f-478c-bbcc-0405cce72103",
"~thread": {
"thid": "7f79736c-818a-4c72-a2b5-5690593ee7dc",
"pthid": "44a79b7c-b900-4f58-be10-7f85c5524bc0"
},
"did": "8M7v4PMd8mgYUCTUJRyS3C",
"did_doc~attach": {
"@id": "455c55ea-b407-4289-bb28-e0880fada760",
"mime-type": "application/json",
"data": {
"base64": "eyJAY29udGV4dCI6ICJodHRwczovL3czaWQub3JnL2RpZC92MSIsICJpZCI6ICJkaWQ6c292OjhNN3Y0UE1kOG1nWVVDVFVKUnlTM0MiLCAicHVibGljS2V5IjogW3siaWQiOiAiZGlkOnNvdjo4TTd2NFBNZDhtZ1lVQ1RVSlJ5UzNDIzEiLCAidHlwZSI6ICJFZDI1NTE5VmVyaWZpY2F0aW9uS2V5MjAxOCIsICJjb250cm9sbGVyIjogImRpZDpzb3Y6OE03djRQTWQ4bWdZVUNUVUpSeVMzQyIsICJwdWJsaWNLZXlCYXNlNTgiOiAiNTFGVUJRaU5XS0drenl4b3o5S0t1WWhvWEE5d2IzUmI5SlpTQW16eURhekwifV0sICJhdXRoZW50aWNhdGlvbiI6IFt7InR5cGUiOiAiRWQyNTUxOVNpZ25hdHVyZUF1dGhlbnRpY2F0aW9uMjAxOCIsICJwdWJsaWNLZXkiOiAiZGlkOnNvdjo4TTd2NFBNZDhtZ1lVQ1RVSlJ5UzNDIzEifV0sICJzZXJ2aWNlIjogW3siaWQiOiAiZGlkOnNvdjo4TTd2NFBNZDhtZ1lVQ1RVSlJ5UzNDO2luZHkiLCAidHlwZSI6ICJJbmR5QWdlbnQiLCAicHJpb3JpdHkiOiAwLCAicmVjaXBpZW50S2V5cyI6IFsiNTFGVUJRaU5XS0drenl4b3o5S0t1WWhvWEE5d2IzUmI5SlpTQW16eURhekwiXSwgInNlcnZpY2VFbmRwb2ludCI6ICJodHRwOi8vMTkyLjE2OC4wLjEwOjgwMzAifV19",
"jws": {
"header": {
"kid": "did:key:z6MkqopNJzgVesySmHK3YthpNvW4bWAKmcTW6kR1VoADjqn3"
},
"protected": "eyJhbGciOiAiRWREU0EiLCAia2lkIjogImRpZDprZXk6ejZNa3FvcE5KemdWZXN5U21ISzNZdGhwTnZXNGJXQUttY1RXNmtSMVZvQURqcW4zIiwgImp3ayI6IHsia3R5IjogIk9LUCIsICJjcnYiOiAiRWQyNTUxOSIsICJ4IjogInFMUzRScHBBeTNuZUdVNThjTHo2MGcyaVE5WUN4ZU04YTA1aXl5OGRwR1EiLCAia2lkIjogImRpZDprZXk6ejZNa3FvcE5KemdWZXN5U21ISzNZdGhwTnZXNGJXQUttY1RXNmtSMVZvQURqcW4zIn19",
"signature": "LV-t-QUyCvYnh1C_VXMYkfX-Q-BRprpOy3kq47HVTMhmFOkrzEPHl9JN0TxkYsmXnGsCifdOBIVrQYSu8gBtCg"
}
}
}
}
When AcaPy sends a Request after receiving an Out-of-Band Invitation, it signs the attached Did Document with the key contained in that Document - it does NOT sign it with the invitationKey
This is expected. The requester is not the inviter and therefore wouldn't be able to use the invitation key
When AcaPy sends a DidEx Response as reply of a DidEx Request, it signs the attached Did Document with the invitationKey, instead of the key contained in that Document
There's been a lot of ambiguity around this, but as I understand it, it ONLY needs to be signed if the invitationKey is different than the did document key. In addition, the key used to send the request/response message MUST match with a key inside the did document.
An attached DidDoc in a DidEx Response sent by AcaPy is not signed by the owner of the Did within the Doc. Instead it is signed by whoever created the attachment. Is that ok?
A rough DidEx Responder could attach a doc with the did that he does not own.
CrossRef: https://github.com/hyperledger/aries-cloudagent-python/issues/2098