openwallet-foundation/credo-ts

How to handle proof challenge if it comes from a scanned QR code

trta2352 opened this issue · 4 comments

After scanning a QR code and decoding the base64 we have this information:

message = {
   "comment":null,
   "request_presentations~attach":[
      {
         "data":{
            "base64":"eyJub25jZSI6ICI1MjA1MDgwMjg0MjU5OTU4MTMzODMxNjUiLCAibmFtZSI6ICJEaWdpdGFsIElEIFByb29mIiwgInZlcnNpb24iOiAiMS4wIiwgInJlcXVlc3RlZF9hdHRyaWJ1dGVzIjogeyI0Y2I3MzI1YS0yMWU4LTRkOTQtOTQ4MS00OTU2OGU3MmMyNzYiOiB7Im5hbWUiOiAiZmlyc3RfYXR0cmlidXRlIiwgInJlc3R11110aW9ucyI6IFtdfX0sICJyZXF1ZXN0ZWRfcHJlZGljYXRlcyI6IHt9fQ=="
         },
         "mime-type":"application/json",
         "@id":"libindy-request-presentation-0"
      }
   ],
   "@type":"did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/present-proof/1.0/request-presentation",
   "@id":"ff241890-8196-4332-b12a-b477cf1b4551",
   "~service":{
      "routingKeys":null,
      "recipientKeys":[
         "5apkTCNGL7yzYc1aC3eYSTL97bMi8hjtapbho8sNiuTM"
      ],
      "serviceEndpoint":"https://modified-service-endpoint.cloud"
   }
}

And the request_presentations~attach.data when decoded is:

presentationData = {
                 nonce: '1080322306963377408407944',
                  name: 'Digital ID Proof',
                  version: '1.0',
                  requested_attributes: {
                    '87913420-8fda-4a59-ad84-689824ca1081': { name: 'first_attribute', restrictions: [] },
                  },
                  requested_predicates: {},
                };

How do we register this proof challenge in the wallet so we can appropriately respond to it? Previously the first JSON was used in this function agent.receiveMessage(message), which in the latest versions is depreciated.

You should be able to pass the encoded URL directly to agent.oob.receiveInvitationFromUrl. Or you can also call agent.oob.parseInvitation() if you don't want to receive it directly.

It will now be converted into an out of band invitation and added as an attachment if it's a legacy invitation. This way the flow for using OOB invitations with attachments or legacy connectionless messages the same

In that case it's best I think to construct an out of band invitation yourself. this is the implementation in AFJ:

// Legacy connectionless invitation
const messageJson = JsonEncoder.fromBase64(parsedUrl['m'] as string)
const agentMessage = JsonTransformer.fromJSON(messageJson, AgentMessage)

// ~service is required for legacy connectionless invitations
if (!agentMessage.service) {
  throw new AriesFrameworkError('Invalid legacy connectionless invitation url. Missing ~service decorator.')
}

// This destructuring removes the ~service property from the message, and
// we can can use messageWithoutService to create the out of band invitation
// eslint-disable-next-line @typescript-eslint/no-unused-vars
const { '~service': service, ...messageWithoutService } = messageJson

// transform into out of band invitation
const invitation = new OutOfBandInvitation({
  // The label is currently required by the OutOfBandInvitation class, but not according to the specification.
  // FIXME: In 0.5.0 we will make this optional: https://github.com/hyperledger/aries-framework-javascript/issues/1524
  label: '',
  services: [OutOfBandDidCommService.fromResolvedDidCommService(agentMessage.service.resolvedDidCommService)],
})

invitation.invitationType = InvitationType.Connectionless
invitation.addRequest(JsonTransformer.fromJSON(messageWithoutService, AgentMessage))

Is there a specific reason you're using m? Is it common to use that for these types of messages? In that case we can also add that one to the parse method in AFJ