RFC 0116: RFC Discussion/Questions

[kdenhartog]

In RFC #116 there's a request_type attribute included in the evidence_request message. Then when the sender is processing the request_type object in the evidence_response format they need to reference back to the previous message they sent in order to process the message. Could we include the request_type attribute in someway for easier processing of the response?

[kdenhartog]

Should we limit the evidence_type attributes (Address, Identity, or Photo) or can we extend this to other types? For example, using a birth certificate as evidence could be useful. However, I haven't considered the implications of processing this data before writing this question.

[kdenhartog]

I get the intuition that this protocol could be embedded into a credential. I read the Why peer DID protocol section and didn't understand the distinct advantages that using a protocol would provide over containing this data within a credential.

For example, a credential schema like this:

{
     "evidence_type": "string",
     "evidence_hash_digest": "string",
     "evidence_url": "https://dropbox.com/other/data/for/url",
}

This schema could also be contain the legitimate data contained on the physical document to encourage the transition from images to digital credential infrastructure.

[kdenhartog]

Also, if possible I'd like to encourage the use of images being stored by the holder and the digest being signed by the issuer. This way the downloading of the image can't be a correlating factor. I know that this is mentioned as a possibility which is why I wanted to advocate support for it when possible. As you point out though, there are some use cases where this is not possible for legal requirements in which case we have to support the verifier phoning home to the issuer for a copy of the image.

Some discussion for you: @vinomaster Thanks for providing this protocol. I enjoyed reading the use cases as well which made understanding the protocol much easier.

[vinomaster]

a) Could we include the request_type attribute in someway for easier processing of the response?

request-type: Stipulates how the Holder's Agent will manage the document access. The Holder's Agent may prefer to store content by value or reference. This parameter allows the sender (Holder) to tell the Responder (Issuer) how to respond.

b) Should we limit the evidence_type attributes (Address, Identity, or Photo) ?

Please refer to this table which suggests how document types can be used for different evidence categories. SO a Birth Certificate can be used for Identity but not Address or Photo.

c) What advantages of using a protocol would provide over containing this data within a credential?

Credentials represent attestations made by the Issuer. In theory a Credential could be used as a conduit for sending "documents" or access to them but this will raise several issues including performance as well as privacy concerns. For example, do we want a Credential Proof flow to have to process extra data (verbose) when it does not have to? Do we want a Holder to have to share access to original source documents fdr anyone who gets access to their Credential? Again, in theory a Credential can contain anything and everything. In practice, some data exchanges can be handled outside the Credential Proofing flow and on-demand.

d) We have to support the verifier phoning home to the issuer for a copy of the image?

The intent of the protocol is to prevent the need for the Issuer to ever perform a B2B interaction with the Issuer. This is the desire of those that advocate for a centralized B2B sharing model for these documents. My suggestion is that the DID Comm family of protocols allows the Holder to be the control point and direct the communications in s C2B manner. So I do not believe we need to support the phone home interaction. Maybe I misunderstood your comment.

[vinomaster]

Kyle (@kdenhartog): Suggest closing post merge and review of PR #127.

[vinomaster]

@kdenhartog: Kyle post merge and review of PR #141, please close.

[kdenhartog]

On further analysis, I think that this is a good start to getting the use cases working and solving a key business case quickly. I think we can further generalise these protocols so that we can make them core protocols that everyone MUST implement, but I don't think that generalisation should hold up this work. I'll close this issue.