Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarification to Refresh Service to address #458 #501

Closed
wants to merge 2 commits into from

Conversation

Projects
None yet
5 participants
@David-Chadwick
Copy link
Contributor

commented Mar 27, 2019

@brentzundel brentzundel requested a review from ken-ebert Mar 29, 2019

@ken-ebert

This comment has been minimized.

Copy link
Contributor

commented Mar 29, 2019

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
verifiable credential if it is intended for either the verifier or the
holder (or both), or inside the verifiable presentation if it is intended
for the holder only."

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:

  1. It takes the holder out of the transfer of the refreshed credential between the issuer and the verifier. This removes the holder's ability to control their data. When and for how long can the verifier refresh the credential? How does the holder revoke this capability?
  2. Cryptographically how does the holder sign the presentation for the new credential, since the verifier is directly accessing the refresh service of the issuer to refresh the credential?
  3. How does an issuer know that the holder has authorized the refresh of the credential?

In the case of
"or inside the verifiable presentation if it is intended for the holder only."
I don't believe that an issuer can place anything inside a verifiable presentation. Only holders can place data in a presentation.
I also don't see any value to a refresh service in a presentation for a holder's use. The holder is the creator of presentations. Once created, presentations are passed to verifiers. If the presentation is unacceptable to the verifier, the verifier could request a new presentation and request that a holder refresh the credential before submitting a new presentation.

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.

@David-Chadwick

This comment has been minimized.

Copy link
Contributor Author

commented Mar 29, 2019

Hi Ken

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.

@msporny

This comment has been minimized.

Copy link
Member

commented Apr 6, 2019

It is possible that I am still not understanding the refresh service correctly.

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.

@msporny
Copy link
Member

left a comment

I don't think this PR is answering all of the issuer submitter's questions. We need to have more elaboration in there, most likley.

index.html Outdated
for the <a>holder</a> only. In the latter case, this enables the <a>holder</a> to refresh
the <a>verifiable credential</a> before creating a <a>verifiable presentation</a> to share
with a <a>verifier</a>. In the former case, including the refresh service inside the
<a>verifiable credential</a> enables both the <a>holder</a> and the <>verifier</a> to

This comment has been minimized.

Copy link
@msporny

msporny Apr 6, 2019

Member

Syntax error... <> should be <a>.

This comment has been minimized.

Copy link
@David-Chadwick

David-Chadwick Apr 7, 2019

Author Contributor

Done!

@msporny

This comment has been minimized.

Copy link
Member

commented Apr 10, 2019

We discussed this on a call today and are going to attempt to produce non-normative text to resolve the various concerns. There will be a new PR, which we will note below.

@msporny msporny closed this Apr 10, 2019

@TallTed

This comment has been minimized.

Copy link
Contributor

commented Apr 15, 2019

Closing a circle -- is #544 the new PR?

@brentzundel

This comment has been minimized.

Copy link
Member

commented Apr 16, 2019

Closing a circle -- is #544 the new PR?

yes

@msporny msporny deleted the Refresh branch Apr 24, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.