Added a new section on Subject NE Holder

[David-Chadwick]

Updates to #134 are as follows

1. Changed the diagram format to .svg
2. Correctly formatted the JSON
3. Removed the .DS store file

---

Preview | Diff

[msporny]

I don't believe this approach is going to achieve consensus due to the various conflicts with delegation and ocap-ld. It feels like we're building a very dangerous form of ACL here and I'd rather not do anything than do the wrong thing. We will need @cwebber, @dlongley, and @erights to weight in.

[msporny]

This will almost inevitably lead to security issues. When you allow the sender of a message to claim their relationship to a subject, it enables them to lie. A better approach would make the subject assert their relationship to the holder via a Verifiable Credential that would be placed into the Profile (also, we're changing this language to Presentation, shortly... but the PR should keep using the old language).

[David-Chadwick]

I agree, and I had thought of that potential security vulnerability already. It can be solved, but it places an extra burden on the verifier to validate this relationship in order to close the vulnerability. Clearly it is better if the subject can assert the relationship for the verifier, but this is not always possible e.g. when the subject is a pet, or a young child, and the holder is the pet's owner or parent. Thus we have to have a way of covering this situation as well, which is why this mechanism is proposed. So rather than remove the facility, we should add appropriate text to cover the situation.

[cwebber]

If it isn't always possible, how does any verifier know when or when not to enforce the relationship check?
And it doesn't seem secure at all to me to allow a situation where the verifier can't check that the subject agrees to the relationship... if Bobby is the child, and Alice is claiming to be her mother, but Bobby can't confirm or deny, what do we do in the case that Mallet is claiming to be Bobby's parent as well but is acting maliciously?

[David-Chadwick]

Further down, Manu suggested that this issuer could state the relationship between holder and subject in another VC. This can also be used to solve the issue of for example, a parent speaking on behalf of their child. The issuer validates that the parent is the parent of the child, then issues the child's VC to the parent along with a second VC that states the relationship between the parent and the child.

[cwebber]

Right, ok... so if you trust the issuer you trust the relationship. I think that's the right approach for relationships.

[msporny]

It would be more secure if the subject states the relationships instead of the holder.

[David-Chadwick]

As stated above, this is not always possible, which is why this Note was added.

[msporny]

-1, significant change to the data model that creates security vulnerabilities as outlined above. In addition to the security vulnerabilities, it unnecessarily complicates the data model by special casing subject-holder relationships when those relationships are expressible as Verifiable Credentials. We should re-use the data model we have to express these relationships.

[David-Chadwick]

Can you please say what your alternative solution is for parent-child, pet owner-pet, etc. If you do not have one, then this property should be retained.

[msporny]

-1, this special cases claim.id for this use case. There is a cleaner way of accomplishing the establishment of the relationship. I'll try to suggest an alternative PR that does this such that we have a means to compare the two.

[David-Chadwick]

Ok great, I look forward to seeing it :-)

[msporny]

relationships should be just another verifiableCredential that is issued by the subject.

[David-Chadwick]

Its not always possible, unfortunately.

[msporny]

I'm not sure what "delegate" means... it feels vague. Does it mean "I delegate this entity to share my attributes"? Or does it mean "I delegate this entity to act on my behalf"? Delegation needs to be very specific about what is being delegated and I'm concerned that we are not doing that with this PR.

[David-Chadwick]

It means the holder is a delegate of the subject (i.e. a standard subject-relationship-object triple in which the holder is the subject and the relationships parameter specifies the latter two). So it is neither of your interpretations. So 'delegateOf' might be clearer.

[msporny]

We should use specific values in examples and not meta values.

[David-Chadwick]

No problem, can do

[msporny]

Why don't they just issue another credential that specifies the relationship in the credential itself? Why do we need to extend the core data model to do this?

[David-Chadwick]

This is a good idea. I like it, and it simplifies the task of the verifier, since it only needs to trust the issuer and not rely on the holder. Of course it now places the burden on the issuer instead of the verifier, but that's OK since the issuer needs to have a good reason for giving the VC to a holder who is not the subject.

[msporny]

This prevents a variety of delegation scenarios... again, ocap-ld seems like a much better fit than what is being proposed.

[David-Chadwick]

If it can be done in OCAP it can be done with VCs :-)

[cwebber]

This has been said several times (and discussed elsewhere), but it isn't the case. Verifiable Credentials are extremely useful for a different purpose than ocaps. VCs can be used to "extend a record" of another entity by saying all sorts of things about them. Alice is tall, Alice has blue eyes, Alice graduated from Harvard, etc etc. That's all great and extremely useful. But when we extend Alice's record to say "Alice can do this" via VCs that is creating an Access Control List. ACLs are about authority by identity and ocaps are about authority by possession. These are not equivalent, and this misunderstanding even has a name as the "equivalence myth" as discussed in Capability Myths Demolished. For more on why ACLs fall apart, the paper ACLs Don't goes into detail.

These are not functionally the same. Verifiable Credentials can talk about all sorts of things, and does not specify an invocation algorithm, and its termsOfUse "attenuation" can be purely advisory. Ocap-ld can only talk about one thing, which is the granting of authority to some cryptographic material (note I say cryptographic material, not entity, since this is merely the mechanism by which we activate the "invokeable possession" of the capability), and it does have a very specific invocation algorithm that either succeeds or fails. We can't use ocap-ld to talk about Alice's eyes and it's actually critical that we can't because we aren't really talking about Alice, we're instead putting some capability into her possession. This difference is important.

On the difference between ACLs and ocaps, which I fully acknowledge is difficult to perceive (and ocap literature is a heck of a slog to go through), I think the explaination of capabilities in "E in a Walnut" explains it well (ignoring whether or not it's a good idea to have guns in your house at all especially with children around):

Principle of Least Authority (POLA)

When you buy a gallon of milk at the local 7-11, do you hand the cashier your wallet and say, "take what you want and give me the rest back?" Of course not. In handing the cashier exact change rather than your wallet, you are using the Principle of Least Authority, or POLA: you are giving the cashier no more authority than he needs. [...]

Children with your ID badge

Suppose all security in the physical world were based on ID badges and ID readers. At your home you might put an ID reader on your door, another on your CD cabinet, and another on your gun vault. Suppose further you had to depend on 4-year-old children to fetch your CDs for you when you were at the office. How would you do it? You would hand your ID badge to the child, and the child could then go through the front door and get into the CD cabinet. Of course, the child with your ID badge could also go into the gun vault. Most of the children would most of the time go to the CD cabinet, but once in a while one would pick up a gun, with lamentable results.

Keys

In the real physical world, if you had to depend on children to fetch CDs, you would not use an ID badge. Instead you would use keys. You would give the child a key to the front door, and a key to the CD cabinet. You would not give the child a key to the gun vault.

[...]

The "children" are the applications we run. In blissful unawareness, we give our ID badges to the programs automatically when we start them. The CD cabinet is the data a particular application should work on. The gun vault is the sensitive data to which that particular application should absolutely not have access. The children that always run to get a gun are computer viruses like the Love Bug.

In computerese, ID badge readers are called "access control lists". Keys are called "capabilities". The basic idea of capability security is to bring the revolutionary concept of an ordinary door key to computing.

[cwebber]

Here is another, less gun-involving metaphor, which may or may not have been based on a real scenario (I was told it at Rebooting Web of Trust):

Alan's garage was under construction, so he needed to move his car someplace. He asked Mark if he could store it in his garage, and Mark unhesitatingly said sure. Mark handed his garage key to his son, and Mark's son handed it to Alan, and Alan stored his car in Mark's garage. Later, Alan wanted to store a file on Mark's computer, and asked Mark to give him his password so he could upload the file. Mark immediately objected uncomfortably to the idea. Why?

• As an exercise for the reader, what does Mark's reaction in both cases tell us about ACLs versus ocaps?
• As a bonus exercise, let's say we have the same scenario but instead let's say that Alan wants to store a file on Mark's employer's file storage service, of which Mark has access (but is forbidden to allow non-employees to upload to his account). In this scenario Mark does give Alan his corporate password, and Alan successfully logs in and uploads a file (and, we hope, does nothing else naughty). What does this tell us about forbidding delegation being merely advisory?

[David-Chadwick]

@cwebber I think you are conflating two different things: concepts and formats. There are two different access control concepts, namely: capabilities and access control lists, but they are both still credentials/permissions to do something. There are two different linked data formats currently being proposed: one in the VC spec and one in the OCAP spec. Both formats can be used to store both access control concepts. This is because of the open world linked data assumption, since both formats are built with object properties that are infinitely extensible. I am arguing that only one format is needed, since it can be used to store both concepts. When we remove the subject id from a VC, we have a capability. When we add a subject id to an OCAP we have an ACL. The former has already been done in the VC spec (bearer credentials) and the latter can easily be done by anyone extending the OCAP structure. We have already had lots of discussions about extensibility in the VC WG, and it has often been said that you cannot stop anyone extending the VC structure in any way they wish. So presumably this also applies to the OCAP structure as well. I dont see anything in your current spec that forbids this.

P.S. giving someone your username and password is not delegation, it is masquerade, which is entirely different to delegation.

[cwebber]

Responded to your P.S. here so we can keep this thread about the ocap-ld vs VC stuff.

Now! Actually you and I are maybe in more agreement than may be obvious:

When we remove the subject id from a VC, we have a capability. When we add a subject id to an OCAP we have an ACL. The former has already been done in the VC spec (bearer credentials)

Okay, when it comes to bearer credentials I agree-ish! Without the subject, this does resemble other bearer ocaps. Let's leave aside whether or not it should be a bearer ocap (some discussion about the implications of delegation there, and maybe some other aspects about whether it's a good fit in other ways) but the thing that makes this not dangerous for authority is that we've removed discussion about identity altogether from this credential. There's no risk AFAICT of it being an ACL.

Here's the thing though! ocap-ld supports non-bearer capabilities! You have the full power of a bearer capability if you see it, and ocap-ld is built for things like DIDs and blockchains where the capabilities can be observed without really being "possessed" by other participants. So we do add information about what entity has been granted possession of an ocap, but it's critical that this is only for use of the invocation algorithm (or possibly, after the fact, to observe if abuse has occurred and consider revoking).

and the latter can easily be done by anyone extending the OCAP structure.

You just described the risk perfectly! In the case of the non-bearer ocaps (let's say "certificate style ocaps") if we accidentally start interpreting that same field by which we talk about what material has been granted possession powers and we mix it up with a vocabulary where we "talk about" various entities and extend their record, we accidentally adopt an ACL. Because ocaps should not talk about identity! ld-ocap has a very specific algorithm that passes or fails and we don't care about "reasoning" about what kind of entity a person is. It's very important to keep these separate, and that's why we need a separate vocabulary, because the algorithms that process these datastructures are different.

Does that make sense?

[David-Chadwick]

I am trying to determine where the border between VCs and OCAPs lies. Here is a taxonomy of 6 different types of credential. Which should be encoded as VCs and which as OCAPS, and why? But first some definitions that I am using:

Credential: the token possessed by someone or something that gives them a certain privilege or permission
Permission = the ability to perform an action on an object e.g. drive a car, read a file, delegate a credential
Privilege = the indirect ability to perform an action on an object, by virtue of some other attribute e.g. a role, a position in society, an identity

Based on the above definitions, we have the following 6 types of credential (at least):
i) a bearer permission. This credential states the action and the object e.g. can drive car X. Anyone or anything that possesses this credential can perform the stated action on the stated object.
ii) an identity permission. This credential states (the identity of) the subject, the action and the object e.g. David can drive car X. Anyone who can prove they have the stated identity can perform the action on the object.
iii) a keyed permission. This credential states the cryptographic key material, the action and the object. e.g. Key ID Y can drive car X. Anyone or anything that has the key material Y can perform the action on the object.
iv) a bearer privilege. This credential states the attribute that the holder of the credential possesses. e.g. the bearer is the President of the US. The holder will inherit all the permissions of the President of the US.
v) an identity privilege. This credential states (the identity of) the subject and the attribute that the subject possesses e.g. David is the President of the US. Anyone who has this credential and can prove they are David will inherit the permissions of the presidency.
vi) a keyed privilege. This credential states the cryptographic key material, and the attribute that the holder of the credential possesses e.g. Key ID Y is President of the US.

[dlongley]

@David-Chadwick,

I'm sure others will have something to say here, but here's my initial attempt at breaking things down in a simple way...

An issuer gives you a VC. A verifier gives you an OCAP.

Permission = the ability to perform an action on an object e.g. drive a car, read a file, delegate a credential

This is an OCAP.

Privilege = the indirect ability to perform an action on an object, by virtue of some other attribute e.g. a role, a position in society, an identity

This is a VC with the caveat that the issuer doesn't get to decide what the privileges are -- they simply to make claims about the characteristics/attributes that an identity possesses. It is up to a verifier of the VC to make a decision as to what permissions (capabilities) to give out on that basis. From there, the capabilities can be used without needing the identity information any longer. An OCAP-verifier may require authentication in order to accept an OCAP, but it does not require identity. OCAPs may also be delegated without the use of identity -- again needing only authentication.

OCAPs are for doing things and VCs are for talking about things.

[cwebber]

Let's move any "the roles of ocap-ld and VC" conversation that does not directly impact this PR back to this issue

[David-Chadwick]

this one still isnt resolved
ii) an identity permission. This credential states (the identity of) the subject, the action and the object e.g. David can drive car X. Anyone who can prove they have the stated identity can perform the action on the object.
@dlongley says permissions are ocap, but an OCAP does not require identity.
The above does require identity, so what is it?

[msporny]

We may want to have an "Anticipated Future Work" section in the specification instead of calling this out here.

[David-Chadwick]

As you wish

[davidlehn]

The svg here is an encoded jpeg wrapped in svg tags. Can you export an editable svg from the source image?

[davidlehn]

Mismatched h tags.

[David-Chadwick]

Well spotted, thanks

[David-Chadwick]

I have now updated the diagram with a clean svg produced by google docs

[cwebber]

It is critical to note that a delegateable flag does not absolutely prevent delegation, since an entity can always conspire to delegate out of band (This is not a VC ACL vs ocap thing, this is just a general property about delegation and its inability to be completely prohibited.)

[cwebber]

Responding to this post

P.S. giving someone your username and password is not delegation, it is masquerade, which is entirely different to delegation.

Masquerade is one way to look at things, but I'd say if it is intentional it is a form of delegation, just one that maybe someone didn't want you to do. But let's put passwords aside, just to make further clear that you can't prevent delegation... surely you and I would both agree that in a system that permits delegation, if I set up a daemon to do the delegation for you through my authority, some server that lets you post via this API and can let you do some subset of the things I can do, that this is delegation. I have authority to post files to this server, and the server didn't mind me allowing others to access the API according to their terms of use, but I wanted you to be in charge of uploading files for me, so I set up a little proxy server and delegated that task to you. All is well, and this sounds like delegation, yes?

Now assume the terms of use says "No, delegation is prohibited!" Well, we may be breaking a real-world contract, but from an infrastructure point of view, I could still set up that daemon anyway, even if I wasn't really "allowed" to, and you could still upload files for me, and in that way we could conspire outside of the system. This is still exactly the same functionality as above, except that in this case someone didn't want us to do it. And that's why I say "forbidding delegation is advisory", at least when it comes to the machine-enforceable aspects (outside of machine enforceability, the service provider could still take a legal recourse or cut off service if it was discovered that delegation happened anyway.)

[David-Chadwick]

@cwebber Sure, no-one cannot prevent anyone from delegating anything to anyone else. Just like anyone can become a CA and issue an X.509 cert to anyone by signing the appropriate ASN.1 data structure. But you are missing the point, which is TRUST. The verifier knows who it trusts, and it will not trust me to be a CA or you to delegate a "president of the USA" VC to me.
So the point is, if a verifier's TRUSTED issuer says 'this VC is not to be delegated" then the standard conforming verifier's software will not trust any VC that is delegated from it. Thus in my opinion this is a non-issue, and you are wrong. The terms of use field can be mandatory and can be enforced by the standard conforming software of the verifier.

On a related point, any verifier (and its software) is allowed to be non-conformant to the standard. In other words, a verifier's software is allowed to ignore all the rules in the standard about how to process the various fields, and to do what it wants to do (since the verifier bears all the risk). It could accept that I am a CA, or the president of the USA and let me access all its treasured resources. Well, if you will run non-standard software, what do you expect?

[cwebber]

Let's move any "the roles of ocap-ld and VC" conversation that does not directly impact this PR back to this issue

[dlongley]

"relationship" should call out the specific relationship, i.e. it should be something like "child".

{
   "id": "did:example:ebfeb1c276e12ec211f712ebc6f",
   "child": "did:example:ebfeb1f712ebc6f1c276e12ec21"
}

That would say that the subject (did:example:ebfeb1c276e12ec211f712ebc6f) has a child identified by did:example:ebfeb1f712ebc6f1c276e12ec21.

[David-Chadwick]

@dlongley I will improve the description of the relationship object to make it even clearer, viz:

The Relationship object states the relationship between the subject of the claim, identified by an ID,
and this object, also identified by an ID e.g. a value of "Parent" indicates that the claim
subject is the parent of the relationship object.

So by using this definition, we can see that the relationship object is "did:example:ebfeb1c276e12ec211f712ebc6f",
thus this object is the child of the subject of the claim viz "did:example:ebfeb1f712ebc6f1c276e12ec21",

[dlongley]

Which is the child and which is the parent here? It seems like "relationship" should read "parent":

{
   "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
   "ageUnder": 16,
   "parent": "did:example:ebfeb1c276e12ec211f712ebc6f"
}

That would say that the subject (did:example:ebfeb1f712ebc6f1c276e12ec21) is under 16 and has a parent identified by did:example:ebfeb1c276e12ec211f712ebc6f.

[David-Chadwick]

My answer above answers this question of yours.
The difference in style is that I have created a generic relationship object that can be used in different places, and the value of the type is not fixed but will be defined by external specifications. You have created a property rather than an object, but the property is unknown as it will be specified by external specifications.

[dlongley]

The generic relationship property has no semantics on its own so I don't see it as useful. It also is a break from the graph model where properties establish meaningful links (relationships with semantics) between nodes in the graph.

You either need to define a property in an external spec or a type. The former keeps with the graph model and doesn't require the extra baggage of a meaningless relationship object in the core spec. I think it's the better approach. We also already use exactly this mechanism for extensibility with claims. So we don't have to do anything special.

[David-Chadwick]

Either way you are going to have to define a new type:

• either a new type of VC which contains a new property, e.g. grandson, or
• a new type of relationship in the relationship object, with relationship being a standard property of the generic VC type.

[jandrieu]

From my read, this entire section is conflating two different types of assertions.

There are two places where relationships might be asserted. Either by the issuer--where they add claims to the credential that include their assertions, e.g., about a parent having certain rights wrt a subject child, or by the holder--where they assert in the presentation that they have one or more relationships with one or more entities either identified in attached credentials or appearing as independent identifiers.

I'm not seeing a compelling case for a generic catch-all "relationship" property in either a VC or a VP. Both have built-in ways for the issuer or the holder to add such assertions to the credential or presentation, respectively.

[David-Chadwick]

@jandrieu. Correct, these are the two places that relationships can go.
Its a matter of style whether you want to define a new type of VC, containing a new type of (relationship) property, or have a basic VC and VP containing a relationship object, and define new types of relationship.

[dlongley]

@David-Chadwick,

I don't think it's merely a matter of style. We already have a mechanism for how to do it -- adding a generic "relationship" property would introduce yet another mechanism to do the same thing... that also happens to break expectations on links/properties having semantics as "relationship" does not. This increases cognitive load and creates a more complex system.

[David-Chadwick]

You are also increasing cognitive load by suggesting we have two different ways of doing the same thing
a) when you include a VC in a VP, you duplicate the "VerifiableCredential" type
b) when you include a TermsOfUse in a VC, you do not duplicate the "TermsOfUse" type

[dlongley]

@David-Chadwick,

a) when you include a VC in a VP, you duplicate the "VerifiableCredential" type
b) when you include a TermsOfUse in a VC, you do not duplicate the "TermsOfUse" type

This is not a rule in the data model. That you have made an observation about VerifiableCredential existing somewhere does not mean that a rule exists whereby the presence of a property solely governs whether or not a type must exist. Rather, type exists based on its utility: If there is ever a use for a type, then that type is always attached to its object, regardless of where that object appears in the data model (regardless of property).

The addition of any rule increases cognitive load. However, that someone who does not understand the rule may guess incorrectly as to what it is does not mean it's a bad rule or that additional cognitive load is incurred.

For example, someone may observe that planes land on a runway -- and build one expecting planes to show up. That planes only land on runways does not mean that the system is inconsistent (or requires further cognitive load) because they do not land on every runway. The rule proposed by the observer just wasn't actually the rule. The rule was something else.

[jandrieu]

@David-Chadwick I think you're leaking the vocabulary of claims into the vocabulary of the credential and presentation.

Within both of those objects, there is a place for signers to say literally ANYTHING they want. For credentials, that's in the "claim" field. For presentations, I don't think we yet have consensus on the mechanism, but for now I will assume the holder self-issues a credential and includes that credential in the presentation--in which case both the holder and the issuer have a "claim" property in which they can literally say anything that is representable within JSON-LD within the Credential or Presentation, respectively.

The vocabulary for what is said within claims is open, not closed. You can use foaf, dublin core, rdf, etc., or any combination thereof. Limiting that vocabulary in any way--including elevating certain terms above others--is not only contrary to the open principle behind VCs, those vocabularies are outside the scope of the Verifiable Credentials specification.

There's nothing wrong with a "relationship" property per se as a predicate in a claim. It just doesn't belong somewhere else in the credential. Instead, it belongs in the claim vocabulary. I believe you and I are in agreement that the specification needs to be rigorous its terms. IMO, the best way to do that is to limit the vocabulary to everything that can't be represented in the claim property, i.e., to what is absolutely needed OUTSIDE the claims for a verifier to be able to determine if the claim property was issued by the issuer and remains valid. EVERYTHING else should be in the claims. Including delegatability, relationships, and real-world attributes like AgeOver21 or LicensedToDriveInCaliforniaUSA.

Coming at it from a different direction, consider a presentation where one of the credentials is a marriage certificate (as in the citizenship claim focal use case) and another is a birth certificate, how does the holder or the issuer use "relationship" to specify that the person in the birth certificate is the child of one of the spouses in the marriage certificate? You can't. Because "relationship" on its own is insufficient to capture the complexity of the actual relationships that exist between entities in various credentials.

The answer to that complexity is to allow issuers to use the underlying representational freedom of RDF--as expressed through JSON-LD--to literally say anything--within the claim field. With the right vocabulary, a holder could claim any kind of relationship, such as being the ex-wife of a subject armed services veteran, who is now dead, having been married to him for over 20 years, and thereby claiming spousal retirement benefits. The factual evidence of all of those assertions, in this example, are spread over multiple credentials. The only "relationship" property I can think of for that use case is "It's complicated".

Is there a situation where the Verifiable Credential itself cannot be verified as authentic and current without a "relationship" property?

[dlongley]

@msporny, @jandrieu,

Since you weren't on the call today -- a quick update: We discussed this issue briefly on the call and decided that in order to resolve it we need an alternative solution to the "relationship" property approach put forward here by @David-Chadwick. We need to be clear on how we expect users of the data model to express what they need to when "subject != holder".

[dlongley]

I don't think we need to specify a "relationship" property in our data model. I think we have everything we need -- we just need to indicate that holders may express whatever they would like via self-issued credentials in a presentation. This includes, but is not limited to, the nature of their relationship with any subject in another credential they are presenting.

Per @jandrieu's comment:

Within both of those objects, there is a place for signers to say literally ANYTHING they want. For credentials, that's in the "claim" field. For presentations, I don't think we yet have consensus on the mechanism, but for now I will assume the holder self-issues a credential and includes that credential in the presentation--in which case both the holder and the issuer have a "claim" property in which they can literally say anything that is representable within JSON-LD within the Credential or Presentation, respectively.

A holder could provide a VerifiablePresentation that looks something like this in order to declare relationships to the subject:

{
  "@context":  "https://w3id.org/credentials/v1",
  "id": "did:example:1234",
  "type": "VerifiablePresentation",
  "verifiableCredential": [{
    "@context":  ["https://w3id.org/credentials/v1", "https://w3id.org/legal/v1"],
    "id": "urn:uuid:abc",
    "type": ["VerifiableCredential", "CitizenshipCredential"],
    "issuer": "did:example:xxxx",
    "claim": {
      "id": "did:example:5678",
      "citizenship": "US"
    },
    "proof": "..."
  }, {
    "@context":  ["https://w3id.org/credentials/v1", "https://w3id.org/people/v1"],
    "id": "urn:uuid:def",
    "type": ["VerifiableCredential", "FamilialCredential"],
    "issuer": "did:example:1234",
    "claim": {
      "id": "did:example:1234",
      "child": "did:example:5678"
    },
    "proof": "..."
  }],
  "proof": "..."
}

Our data model already supports saying whatever you want in the claim section of a credential -- this includes whatever personal relationships someone may want to describe. Here the presenter (holder) shares a credential from an issuer (presumably a government) indicating the citizenship of a person and they provide a self-issued credential indicating that that aforementioned person is their child. Of course, some verifiers may require such a credential to have been issued by someone else (or some additional credentials of some sort), but the example simply shows a self-issued credential. The point is that we can reuse our current data model to allow holders to express information regarding their relationship (whatever it may be, no matter how complicated) to the subject of other credentials.

We don't need anything new to do this because we've provided an extension mechanism that already covers it -- and covers any possible relationship that the holder could have with a subject through the open world design and reuse of RDF and JSON-LD technologies.

[David-Chadwick]

@jandrieu I can see the logic of adding relationships to claims, but first I would like to suggest that 'claim' is replaced by 'subject' as was discussed in a previous issue (and conceded to by @dlongley). Then it becomes much clearer that the relationship property, e.g. 'child' is stating that the subject is a child (of some other associated ID). Otherwise a claim containing the property of 'child' could imply that the id associated with this property is the child of the claim subject, which would be wrong. The relationship would be parent, since the subject of the claim is the parent.
You said "Coming at it from a different direction, consider a presentation where one of the credentials is a marriage certificate (as in the citizenship claim focal use case) and another is a birth certificate, how does the holder or the issuer use "relationship" to specify that the person in the birth certificate is the child of one of the spouses in the marriage certificate? You can't. Because "relationship" on its own is insufficient to capture the complexity of the actual relationships that exist between entities in various credentials.' This is true given the current specification of the relationship object, but this can be enhanced in much the same way as the 'terms of use' object which can specify anything. So I am arguing that relationship objects should be like terms of use objects, where the type specifies what type of relationship object it is. But I am happy for a relationship property to be a property of a subject object, where the relationship specified the relationship of the subject to one or more other IDs.

@dlongley Relationships specified in 'presentations' are generally not good enough due to the trust issue. The receiver does not trust the holder, so won't trust any relationships specified by him or her (without further independent verification). Relationships specified in VCs on the other hand can be trusted, because by the trust model, the receiver trusts the VC issuer (otherwise the VC will be rejected). BTW, 'open' design is a non-issue, since you can have open designs without needing to resort to JSON-LD. X.509 PKCs are an open design and can be extended by anyone in any way they want to, providing they follow the rules specified in the standard. This is no different to JSON-LD as it has its own rules.

[dlongley]

@David-Chadwick,

Relationships specified in 'presentations' are generally not good enough due to the trust issue. The receiver does not trust the holder, so won't trust any relationships specified by him or her (without further independent verification). Relationships specified in VCs on the other hand can be trusted, because by the trust model, the receiver trusts the VC issuer (otherwise the VC will be rejected).

The relationships given in the example are in VCs (which are presented in the presentation). I also made this statement that I intended to cover your concern here:

Of course, some verifiers may require such a credential to have been issued by someone else (or some additional credentials of some sort), but the example simply shows a self-issued credential. The point is that we can reuse our current data model to allow holders to express information regarding their relationship (whatever it may be, no matter how complicated) to the subject of other credentials.

To be extra clear -- holders can also present credentials from others (that the verifier would trust) in the same presentation that assert the requisite relationships. The point is that we don't need something new to do this; the data model is already powerful enough.

[stonematt]

@dlongley to produce an example code snippet for Verifiable Presentation that solves the focal use cases, both of which rely and require relationship traversal through Verifiable Credentials. When we originally created the citizenship use case, we created an presentation. You may want to start with the code example that @jandrieu wrote in this document: https://docs.google.com/document/d/1O-PYcHZYvbjbhONRSdSwdCP2cwg77bxadAJQdHdI66A/edit#heading=h.ozqxp6eiffwa - it's also referenced in issue #55

[burnburn]

For tracking purposes, original issue was #106 .

[dlongley]

See #187 for some modeling related to a specific travel use case from our use cases document.

[David-Chadwick]

@dlongley . I have commented on your examples in #187 and broadly they are OK, providing we can resolve the issues concerning the use of the type property

[burnburn]

@David-Chadwick We had earlier agreed that this PR (#169) was okay as long as we separately continued to discuss the 'type' issues. All that was needed was some examples from @dlongley . Now we have those examples, but you have expressed concerns with the type property in them.

Assuming, as previously agreed, that we continue the type discussions elsewhere, what is left to wrap up on this PR? @msporny and @cwebber may want to comment.

[msporny]

Assuming, as previously agreed, that we continue the type discussions elsewhere, what is left to wrap up on this PR?

The section on the Relationship Object needs to be removed as it re-invents a feature that already exists in Linked Data (relationships are expressed via properties, e.g. JSON keys).

[David-Chadwick]

Let me remove the relationship object now that we have examples from @dlongley that circumvent the need for them, then see if the text is acceptable to @msporny and @cwebber