Clarification to Refresh Service to address #458 #501
Thank you for clarifying the language. It makes it more apparent what is going on. However this clarity raises several concerns that were not obvious to me before:
"The issuer can include the refresh service as an element inside the
In the case of an issuer including the refresh service inside a credential to enable a holder to refresh the credential, I can understand the use case and possible ways this could be securely implemented.
In the case of an issuer including the refresh service inside a credential to enable a verifier to refresh the credential, I believe this has extremely negative consequences:
In the case of
I have serious reservations about a refresh service offered to a verifier that bypasses the holder from both a cryptographic assurance standpoint and from the basic model of issuer/holder and holder/verifier pairwise relationships.
It is possible that I am still not understanding the refresh service correctly.
First let me say that I disagreed with adding the Refresh Service to the standard. I don't think it is needed and as you point out an issuer is never going to send a VC to a verifier without prior authorisation. And if prior authorisation has been given, then the verifier would presumably already know where to get the VC so not need to be told inside the VC. I will let Manu argue for the value of this property, as I am not going to defend it.
However, with respect to VPs, these can be sent from the Issuer to the Holder when the VC is first issued. So in this case the refresh service can be in the VP. It is not only the Holder that can create a VP. If the data model implies this then it needs correcting.
This PR has generated far more questions than it's closing and it would take me a very long time to get all three of us on the same page through the issue tracker. I suggest we setup a time to discuss that doesn't take WG call time to get some closure on this PR.