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

vc:credentialSubject semantics #885

Closed
bertvannuffelen opened this issue Jun 24, 2022 · 10 comments
Closed

vc:credentialSubject semantics #885

bertvannuffelen opened this issue Jun 24, 2022 · 10 comments
Labels
pending close Close if no objection within 7 days

Comments

@bertvannuffelen
Copy link

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

@mkhraisha
Copy link

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?

your understanding is correct and reflects the current model.

If I am right, this role is even not at all present in VC.
again accurate statement
The role of "person who owns credential about whom claims are made" is most closely aligned with the holder role, but even then you may be a holder of a credential that is not about you.

@bertvannuffelen
Copy link
Author

Thanks a lot for the confirmation.

@awoie
Copy link
Contributor

awoie commented Jun 24, 2022

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.

@bertvannuffelen
Copy link
Author

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.
The issuer could be the central diploma system of a country.

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).
In this reading the above definition is correct.

What is the best choice?

@lemoustachiste
Copy link

The way I approach it is, if the credentialSubject claim is about the holder, merge them into one (ie, a Diploma).
if the holder and the credentialSubject are related to some extent, then split them. For instance a technical inspection of a car. The claim would be about the car (credentialSubject) but the holder would be the owner of the car.

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.

@bertvannuffelen
Copy link
Author

The way I approach it is, if the credentialSubject claim is about the holder, merge them into one (ie, a Diploma)

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.
Despite in the real world they are the same person, digitally they are very distinct persons.
Unless the claim data is created with actualized information, one must assume that the owner of the claim and the person in the claim are digitally different.

So I would use holder as a possible extension of the credentialSubject, somewhere where you can split the data into something more semantic.

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

    { <John> <owns> <house>.
      <Bank> <finances> <John>
    }

one can create many VC's based on some interpretation of holder and subject: e.g.

  • John is the holder, and house is the credentialSubject, or
  • Bank is the holder and Bank is the credentialSubject
    ...

For me it unclear what the guidelines are for such interpretations, to make it more interoperable.

@lemoustachiste
Copy link

Universally, one cannot rely on that the identification properties of a person when the Diploma was registered are still valid today.
Despite in the real world they are the same person, digitally they are very distinct persons.

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).

For me it unclear what the guidelines are for such interpretations, to make it more interoperable.

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 credentialSubject and holder can be mixed, but holder and credentialSubject can also be split. Maybe v2 will clarify this point but we will have a whole world of credentials that exist with the previous rule. I believe this is like a language, usage makes the rules, and I was just merely sharing how I approach it at this time.

@bertvannuffelen
Copy link
Author

@lemoustachiste thanks for your feedback.

I am trying to learn what is the underlying intend of VC and how it should be best used.

  • In a government context, the administrative process is full of "official documents with historic data on it", which do not match the actual identity of a person, but these historic documents are required for the process.
  • In many countries, an persistent digital identity is legally not possible/politically not supported. (*) That means that assuming that the digital data in the claim may be/is likely not sufficient to do a full universal identification of that person.
    Introducing a persistent URI/ID, or plain text identifying information about a person for public shareable VC's, I do not know if this is going to be accepted.

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.
Then one binds the identity of roles know by the VC description with the information expressed in the claims, without the need to add personal data about the holder/issuer in the claim.
In that case the digital identity can be settled prior doing an VC exchange.
I have the feeling this will resolve also the "semantic interpretation" challenges to a large extend.

(*) Even more complex: Belgium has one, but it is adviced by the Belgian DPA not to use it.

@brentzundel
Copy link
Member

The Data Model defines a "property for the expression of claims about one or more subjects."
and defines a subject as "A thing about which claims are made."

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.

@brentzundel brentzundel added the pending close Close if no objection within 7 days label Jul 28, 2022
@brentzundel
Copy link
Member

No comments since marked pending close, closing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pending close Close if no objection within 7 days
Projects
None yet
Development

No branches or pull requests

5 participants