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

Limit refreshing of verifiable credentials to holders fixes "Refreshing questions" #458 #540

Closed
wants to merge 3 commits into from

Conversation

Projects
None yet
7 participants
@ken-ebert
Copy link
Contributor

commented Apr 8, 2019

Allowing Verifiers to bypass holders during a refresh removes control of credentials from the holder. If Verifiers need an updated presentation, they must request the update from the holder.

@David-Chadwick

This comment has been minimized.

Copy link
Contributor

commented Apr 9, 2019

I dont agree with the proposed update since it still puts the property in the VC. If you do not want the verifier to know this information then it should only be put in the VP from the issuer to the holder and never put in the VC

@dlongley

This comment has been minimized.

Copy link
Contributor

commented Apr 9, 2019

@ken-ebert,

I don't see a reason why a refresh service as specified by the issuer in the VC couldn't be designed to require a special revocable token (e.g. an ocap) from the holder in order for the verifier to refresh the VC as they see fit. There should be no hard requirement that the verifier must ask the holder every time they want to update, rather, the holder can automatically grant access until revoking the ocap.

So, for example, the issuer gives the holder the VC and an ocap for using the refresh service. The holder delegates the ocap to the verifier and may freely revoke it later as they see fit. There is no need to send a new presentation.

@msporny

This comment has been minimized.

Copy link
Member

commented Apr 10, 2019

If Verifiers need an updated presentation, they must request the update from the holder.

There are a whole class of use cases that are prevented if you do this. For example, all public credentials that could be refreshed w/o the holder being present. One of these is a sub use case for Verifiable Credentials Use Case C.1: https://www.w3.org/TR/verifiable-claims-use-cases/#professional-credentials

Think about professional licenses for doctors, like a board certification or information associated with a National Provider Identifier. These are cases where the issuer (medical board) can provide a place where anyone viewing an old credential could go to see the most up-to-date credential. This can happen when the credential has expired (that is, it has not been revoked), or when the old credential is still valid, but the issuer has added information to the credential (like a new medical certification).

Yes, this property could be abused, but the expectation is that digital wallet software is going to highlight that some credentials are more dangerous to share than. For example, I would expect most wallets to warn about credentials w/ traceable identifiers, or credentials with PII... as those would enable the "phone home" use case that you are concerned about (and are the status quo today -- if you have someone's mobile phone number, you have what you need and not putting this feature in the specification isn't going to stop what you're concerned about happening from happening).

In summary - there are legitimate use cases for having refreshService in the credential itself. There are also a myriad of ways of phoning home as soon as you have a very basic set of information on the individual (email and mobile phone number are two universal identifiers used at Equifax, Transunion, etc.) and not having this feature in there is not going to prevent organizations from collecting and using that information.

@msporny
Copy link
Member

left a comment

This is a normative change that was not a bug. We will need to discuss this in the group. I tried to look at this from a variety of different angles to see if there was a way to transform it into a non-normative change and I didn't see an easy way to do this. Open to suggestions...

@David-Chadwick

This comment has been minimized.

Copy link
Contributor

commented Apr 10, 2019

@dlongley makes a very valid point that some VCs are designed to be public because they are for the public good. In these cases I think it is perfectly acceptable for the issuer to be prepared to present the latest VC to anyone who asks for it. (My previous thought was that an issuer would never present a VC to anyone who asked for it, since this violated the privacy of the subject. This was why I originally supported @ken-ebert. I have now changed my mind).

Consequently I would suggest that to resolve this issue we add some clarification text to the document along the following lines:
a)say that adding the refreshService to the VC might only be done when both the issuer and subject are happy for the VC to potentially be released to the public.
b) normally a verifier would not be able to use the refresh info in a VC without either some prior arrangement with the issuer (such as obtaining authn credentials) or some authorisation token from the subject.

@msporny

This comment has been minimized.

Copy link
Member

commented Apr 10, 2019

Consequently I would suggest that to resolve this issue we add some clarification text to the document along the following lines:
a) say that adding the refreshService to the VC might only be done when both the issuer and subject are happy for the VC to potentially be released to the public.

Well sure, but I expect there may be issuers that don't care about what the subject thinks about this (like a medical board would probably be like: "Umm, no, the doctor gets no say wrt. whether or not someone else is allowed to view public information on them."

b) normally a verifier would not be able to use the refresh info in a VC without either some prior arrangement with the issuer (such as obtaining authn credentials) or some authorisation token from the subject.

We could suggest that it is ill advised for issuers to put the refreshService in a credential that is either 1) not public information, or 2) not protected by some sort of protection that is acceptable to the subject of the credential.

... or something to that effect.

@agropper

This comment has been minimized.

Copy link

commented Apr 10, 2019

@David-Chadwick

This comment has been minimized.

Copy link
Contributor

commented Apr 10, 2019

I think a third constraint that we should add is
c) this service is only expected to be used when either the credential has expired, or when the issuer does not publish status information

@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

Was #544 the new PR?

@brentzundel

This comment has been minimized.

Copy link
Member

commented Apr 16, 2019

Was #544 the new PR?

yes

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.