-
Notifications
You must be signed in to change notification settings - Fork 110
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
vc:credentialSubject semantics #885
Comments
your understanding is correct and reflects the current model.
|
Thanks a lot for the confirmation. |
That is one of the reasons why I started this thread #882 . IMO, it is still a common use case if someone presents VCs as a VP and the verifier needs to check whether at the time of presentment, the original subject (defined by an id or not) of the VC presented the VP. |
After rereading #882, I am still confused with the above definition. Consider a diploma (as the examples in the VC spec) then the CredentialSubject is for me the "Diploma" and not the person who has got the diploma. The holders of this claim are the university that issued the credential and the person that has got the diploma. But the same could be modelled as The credentialsubject is the person who got the diploma, the issuer is the university and the diploma is implicit (namely enforced by the credentialtype). What is the best choice? |
The way I approach it is, if the credentialSubject claim is about the holder, merge them into one (ie, a Diploma). So I would use holder as a possible extension of the credentialSubject, somewhere where you can split the data into something more semantic. But I agree that this is an implicit rule and could not necessarily work long term in an interoperable ecosystem, at least this impairs potential interoperable presentation layers. |
In the practice is must be split then always because the Diploma is always historic information and the personal information on it is historic: people do change name, gender, haircolor, id, residence, etc. Universally, one cannot rely on that the identification properties of a person when the Diploma was registered are still valid today.
For me holder in abstract VC terminology is the one who holds/own the set of triples (claims), while the credentialsubject is the key entrypoint in the set of triples (claims). As a Bank, I provided money for John to buy a house. Then John can be stated he owns the house, but also the Bank can state it owns the house (if the loan is not payed back). So for the same triples
one can create many VC's based on some interpretation of holder and subject: e.g.
For me it unclear what the guidelines are for such interpretations, to make it more interoperable. |
If you're going this way then the whole Self Sovereign Identity technology is void by essence. You would need, for it to work, at any given point in time, and regardless to the fact that you changed gender/family name (the rest does not apply to identity - or anymore because maybe in the 70s you could change haircut, grow a beard and be unrecognizable, ie Jacques Mesrine), to be able to prove you were said person digitally. On the contrary I believe digital identity should be persistent to the extent that is desirable for the user. What shouldn't be is your relationship, if one does not want it to be. If you order something off a website, you may want a one off identity (up until delivery at least). But if you have a diploma, you'd want it to be valid for your whole lifespan (and maybe more).
But, to your point, and that's what I tried to highlight, it is not clear at this time what is the preferred way from an interoperable perspective. The spec says the concepts of |
@lemoustachiste thanks for your feedback. I am trying to learn what is the underlying intend of VC and how it should be best used.
I am struggling with this. But maybe I overlook an VC implementation note, e.g. namely VC's with personal data are only sharable within a legal logging secured network? One solution I came up was to introduce skolem constants "the holder", "the issuer", and use these in the claims. (*) Even more complex: Belgium has one, but it is adviced by the Belgian DPA not to use it. |
The Data Model defines a "property for the expression of claims about one or more subjects." This makes it clear to me that @bertvannuffelen is correct when he says that, "Subject in this property stands for anything in the world: a diploma, apples, cars, ownership of boats, etc." I believe this issue should be closed. |
No comments since marked |
Hi,
I have encountered implementations of VC were vc:credentialSubject is interpreted as "The person about which claims are made and who owns the credential."
In my understanding of this property this is not the intentional semantics.
But vc:credentialSubject is a collection of statements (claims) which trust is cryptographic proven.
Subject in this property stands for anything in the world: a diploma, apples, cars, ownership of boats, etc. Right?
If I am right, this role is even not at all present in VC.
kr,
Bert
The text was updated successfully, but these errors were encountered: