On the Ecosystem Overview

[RieksJ]

There have been a few issues mentioning confusion around terminology and roles, e.g. #57 (@rvarn), #64 (@msporny), and #68 (@jandrieu). I am regularly confused as well, for the same (or different) reasons.

Consider the Ecosystem Overview (section 1.2). It defines 'holder' as an 'entity that is in control of one or more verifiable claims'. The examples (students, employees, and customers) suggest that holders are natural persons (perhaps also organizations). Examples of 'Inspector-verifiers', i.e. 'entities that receives one or more verifiable claims for processing', include employers, security personnel, and websites. Figure 1 shows that holders can present profiles to inspector-verifiers.

A difficulty here is that none of the examples of 'holder' can actually present profiles to websites. They can only do so if a process exists that runs on some hardware (e.g. a running app) that either represents the holder, or acts on behalf of the holder. The first requirement for holders (section 1.3) states 'Holders MUST receive and store verifiable claims from issuers through an agent that the issuer does not need to trust.'

The examples given in the definition for issuers suggest that they are non-electronic actors. Since organizations and governments can only act by proxy, I suggest to add the requirement that Issuers MUST issue verifiable claims through an agent that represents/acts on behalf of them.

The examples given in the definition for inspector-verifier is ambiguous: 'employer' and 'security personnel' are obviously non-electronic entities, but 'website' is not. The difficulty here is that employers and security personnel might represent/act on behalf of some other entity, but also represent/act on behalf of themselves. A website cannot: it always represents/acts on behalf of some other (non electronic) entity.

The VC document in its current state is ultimately about claims, i.e. electronic data (this follows from the definition of verifiable claim as being tamper-resistant and cryptographically verifiable). It is not about paper credentials (passports etc.). Since neither organizations, nor natural persons are capable of issuing, sending, receiving, storing or processing such claims, the ecosystem should be two-tiered:

1. one tier in which we exclusively talk about non-electronic entities, such as people, organizations and things. In this tier, we can also define (sort of at the 'information level') how such entities relate to one another, what their concerns/business is with one another, how they see the world, manage their risks etc.
2. the other tier in which we exclusively talk about electronic entities that represent/act on behalf of one (or more) entities from tier 1. In this tier, we can define the technical protocols, interfaces that such entities provide or need, data structures for claims/credentials, etc.

Then, we need to define semantically meaningful relations between entities of different tiers. Explicitly specifying such mappings will allow us to (formally) specify ways in which entities in tier 2 can draw conclusions based on VCs that they have acquired/receieved, and provide correctness proofs.

It will also allow us to better formulate texts. For example, the text "A verifiable profile is a profile that is tamper-resistant and whose contents are typically counter-signed by the holder or subject." could be rephrased as "A verifiable profile is a profile that is tamper-resistant and whose contents are typically counter-signed by an agent that represents/acts on behalf of the holder or subject"

I suggest to add a definition for the term 'agent' (or 'electronic agent', or 'e-agent'), as "a software process running on a computing device, representing and/or acting on behalf of a non-electronic agent", examples of which include webservers and (mobile) apps. Then, the text should be reviewed so as to ensure that wherever appropriate it is unambigously clear when an agent is referred to and/or the non-electronic actor it represents.

[msporny]

@RieksJ Thank you for the well thought out suggestion to change the spec text. I think I agree with the suggestion and will attempt to make these changes.

The only concern I have is overly complicating the document with extra things. The reason we didn't bring agents into the mix yet is because we wanted to provide an overview without the technical details, the assumption being that you will always need agents to do things on your behalf. That said, if it's leading to confusion for you, it'll probably lead to confusion among other people. So, I'll give it a shot and see if the modifications are easier to read / make more sense.

Not ETA on when I'll get the changes in there, I have a big backlog of edits to do before W3C TPAC in early November 2017.

[RieksJ]

Hoping to make your life a bit easier, I have drafted a picture of how I currently envisage how this might be:

Legend:

• a blue rounded rectangle represents a specific (electronic) functionality - identified by the name of the rectangle. Note that electronic agents (e.g. webservers, browsers, apps) may be capable of exhibiting multiple such functionalities (e.g. a webserver may both function as a relying party and as an attestation provider).
• a blue line represents the existence of one or more protocols as the connected agents interact.
• green pawn(sets) represent non-electronic agents (e.g. organizations, governments, people) that behave in a manner that they can determin themselves (which electronic agents cannot: their behavior is determined by hardware, the software they run and the messages they receive through their various interfaces).
• a green dotted line (between a non-electronic agent and an electronic agent) represents the fact that the non-electronic agent exerts control over the electronic agent. E.g. the Dutch government exerts control over the (electronic) attestation provisioning agent.
• a red document-symbol represents a coherent and consistent information-blob, for which a (digital data) representation exists (somewhere). An information-blob can be described by an ontological/conceptual model with rules that support a closed world assumption.
• a red dashed line between a document symbol and an electronic actor means that the electronic actor has access to the data representing the information in the information-blob.

The crux here is that each electronic functionality requires a relation between the controlling non-electronic agent and the information blob that is specific for that functionality - this has to be elaborated. For example, whenever a wallet accesses an information blob, this would be a set of attesations/credentials (portfolio), and the wallet must ensure that the subject of every such attestation/credential is the non-electronic actor that controls the wallet at that particular point in time. In a similar fashion, whenever the attestation provider accesses an information blob, this would be a set of truths (e.g. some database/administration/registration), and the attestation provider must ensure that these are the truths of the non-electronic actor that controls the attestation provider.

Does this help?

[msporny]

Yes, it does help. The diagram is a bit too complex to open with, but I'll play around with various representations until we at least draw a line between the roles and the software used by the role to effect change in the system.

When we first created the diagram, we didn't want to expose the reader to too many details. So, perhaps the best place for all of this is in an appendix that we refer the reader to from the simpler diagram.

[RieksJ]

Maybe this is simpler:

The green things in the figure each represent an actor that is capable of engaging in business transactions and making independent decisions (which I classify by the term'Party'). Typical examples would be individuals, or organizations. The ability of a Party to engage in business transactions and making independent decisions implies (to me) that it must have a set of concepts, relations (between such concepts) and rules (i.e. an Ontology) by which he models the way he sees the world. Also, it has a set of symbols that refer to entities that it knows to exist. I classify such symbols by the term 'Identifier', because every symbol identifies an entity (in the real or electronic world) within the scope of this Party's knowledge.

The figure shows that parties can play different roles: the Issuer role, the Holder role and the Inspector-Verifier role. While a single party may play different, and even all roles, in a single session with another Party, it should limit itself to a single role. The role that a party plays in a session defines the kinds of services that it provides and/or the kinds of requests it sends to the party it has the session with.

The blue things in the figure each represent an (electronic) actor, i.e. an actor embodied as (a software component running on) a computing device (which I classify by the term 'Agent'). Typical examples would be a mobile app, or a web service. Agents do the actual acting in sessions, i.e. the sending of requests and the provisioning of services. In every session, an Agent will do so on behalf of a single party, in a role that the party has specified/indicated that the Agent should play in that session.

The red things in the figure each represent a linked-data graph, that is a (populated) subset of the ontology of a party (green thing). For the time being, I call that a 'Profile', but if that triggers unconstructive conversations, I'm happy to use a different term (this goes for all terms that I use).

The blue arrows show the direction in which credentials/VCs propagate from one agent to another, thereby conveying knowledge (that may have been attested to by one or more Issuers) between parties.

The basic pattern that we can recognize here is that whenever an Agent participates in a session, it acts on behalf of a Party, and uses a Profile that represents (a part of) the knowledge of that same Party.

[stonematt]

should we accept the new diagram and close the issue?

[RieksJ]

W.r.t. the complexity of the issue: I appreciate that we should make everything as simple as possible, but not simpler. One of the focal points in an ecosystem such as the one we're trying to describe, is the interaction between (1) the often fuzzy, nondeterministic way that people and businesses operate and (2) the support of this way of working by the formal and deterministic ways that electronic agents work. Basically, electronics get to make decisions on behalf of people/businesses. That is not something to take lightly and there is a real risk of oversimplification here.

I like the idea of getting the diagram with appropriate explanation in an appendix, and cover it with a simpler, higher-level picture and text in the main body. Let me know if you think I can help out.

[David-Chadwick]

Whilst I quite like the diagrams, neither of them are optimum. One issue I have with the first version of the diagram is that it confuses subject and holder. The holder may not be the subject but the diagram implies it is. On the other hand, the second version of the diagram does not have a subject actor but implies the holder is the subject through the red dashed lines. Can you redo either of the diagrams showing that there are both subject and holder roles, which may or may not belong to the same physical person.

[RieksJ]

I largely agree with @David-Chadwick's remarks on the diagrams. It does suggest the confusion there is between 'Holder' and 'Subject'. And they are different. 'Holder' is a role in the ecosystem that is played by a real-world entity such as a person, organization, or thing. 'Subject' however is (a reference to) a real-world entity (which may not even be capable of playing the role of Holder).

I think we should elaborate on/clarify this, and make not only the distinction explicit, but also the relation that a subject and holder may have. This issue is related to

• guardianship. This is where the holder is 'someone else as the subject', which is a need that is expressed for various reasons. As a side-effect, it allows me to be the holder of statements with a subject that refers e.g. to a camera of mine. There is however no reason why I should not be able to hohold statements with subjects that refer to any entity that I know to exists. The relation between 'subject' and 'holder' would then be: "a subject is (a reference to) an entity that is known to exist by the entity that fulfills the role of holder".

• issue #55 (multiple subjects in a credential). If we go for the above relation, there is no reason why subjects would necessarily be limited to the one referring to the holder, and statements with different subjects might very well be accommodated.

In short, I suggest to clarify the relation between 'holder' and 'subject' as stated above, and look forward to further discuss this as David suggested in his post in issue #55.

[David-Chadwick]

I think we have a way of differentiating between subject and holder by using the ID in the credential to be the ID of the subject and the ID in the profile to be the ID of the holder. If we wanted to show the relationship between the subject and the holder, when Subject NE Holder, then this could be indicated by a new property ('relationship') of the profile. If the credentials in the profile belong to a set of different subjects, then again a new property of the profile ('multi-subject') can state this.

[David-Chadwick]

@RieksJ Can you look at the two PRs that are currently open. One clarifies that credentials can contain multiple subjects and one is about Subject NE Holder. Do these PRs addresses your concerns in this issue?

[RieksJ]

@David-Chadwick I have had a quick look. Here's my 2 cents:

W.r.t. the multiple subjects, I like the terseness of the paragraph you suggested. However, it does not explicitly note that there may be multiple subjects, which I think it should (it was the whole point of the discussion). I also like the precise use of words such as 'optional', 'may', 'should' etc where that is appropriate. I also think that a further discussion about the nature of credentials (part of which you described in your Chapter 6 contribution) may straighten out any other issues, so for now I have no problems with this PR.

W.r.t. this Chapter 6 that you wrote, here are my remarks/observations:

• I can't seem to view Figure 7 (Subject Holder Relationships in Verifiable Credentials).
• w.r.t. 6.1 Credential Uniquely Identifies Subject. In the light of the more general purpose that I think the relation property should have (see further down), I think we should allow (perhaps even require) that if there is a mapping between subject-id and holder, it should be explicitly stated in the credential.
• w.r.t. 6.2 Holder Acts on Behalf of Subject. I think the relationship property should have a broader meaning - not just useful for 'acting on behalf of', but for mapping any relation between identifiers in a claim/credential issued by an issuer, and identifiers that are owned/used by the holder. For example, consider the claim {id1} is the father of {id2}. If you have kids, you may want your holder-id to map to {id1} for every {id2} that represents a kid of yours. However, you may also want your holder-id to map to {id2} for an {id1} that represents your father. And there is more: you not only have your holder-id (which basically is some {id} within your information context (knowledge), but you also have other id's by which you refer to entities that you know (your kids, your father, ...). You may want to map these identities to to whatever {id} appears in a claim that you got from some issuer. My guess is that such a generic mapping, combined with well-designed ontologies/schema's, may solve many other issues as well, including some that you describe subsequent sections.
• w.r.t. 6.3 Subject Delegates to Holder. I am very hesitant about the implications that such a construct may have. I would currently oppose a generic delegation property, because it would allow me to delegate a claim that I am over 18 to pretty much anyone. I currently also think that it may not be necessary once we have the generic mapping (using the relation property) as I mentioned in the previous bullet.
• w.r.t. 6.4 Issuer Authorises Holder. I think we don't need this. When an issuer does not want a holder to possess a credential that describes a subject who is not the holder, then the issuer should not issue it.
• w.r.t. 6.5 Holder Acts on Behalf of Verifier or has no Relationship with the Subject, Issuer or Verifier. My guess is that once we have the generic mapping capability, this can be sorted out by defining appropriate ontologies/schema's, and as such can be placed out of scope of the VC standard.

[David-Chadwick]

Hmm. When I open the Preview in the Pull Request then I cannot see ANY of the diagrams, even the pre-existing ones. Can anyone who is familiar with the W3C Github system explain this please, and what the solution is. When I open index.html in my local github copy then I can see all the diagrams.

@RieksJ w.r.t 6.1. I agree. We should be as explicit as we can be in the data model and leave nothing to guesswork (by the Verifier) w.r.t. 6.2. Until we work out a way for the issuer to state relationships between subject identifiers in its issued credential, I would prefer to keep the current Relationships property restricted to the holder stating his/her relationships to the various subjects. Once we have the former, we can see if the format of the latter can be easily changed to cater for both types of relationship, or whether we need two separate JSON constructs for the two different types of relationship. w.r.t. 6.3. I disagree with your assertion that it would allow me to delegate a claim that I am over 18 to anyone. Firstly, the verifier will not trust a subject to claim their own age (as that is no improvement over what we have today). It must be an issuer trusted by the verifier. Secondly trusted issuers will always issue age related credentials with the "delegatable": false property, otherwise that would be a prima facia case for not trusting them :-) w.r.t 6.4. I think we need it if we consider the case where an attacker gets hold of a VC and puts it in his profile without any authorisation. The verifier can see immediately that the issuer has not authorised this holder. So now the attacker will have to prove to the verifier that he has some other sort of relationship with the subject, such as father, brother etc. which may be impossible to do. But a genuine holder who has no relationship with the subject, but nevertheless was authorised by the issuer, needs a way of proving this, and cannot use the Relationships property for this. w.r.t. 6.5 The text saying that it is for further study is still correct :-)

[RieksJ]

@David-Chadwick W.r.t. 6.3, 6.4 and 6.5, I get the impression that I do not understand what it means that a claim is being delegated, what authorizations you envisage that an issuer provides to a holder and why that would be of interest to a verifier. Could you elaborate, please?

[RieksJ]

@David-Chadwick W.r.t. stating relationships between subject identifiers (of an issuer) and identifiers of a holder, and not having given this a great deal of thought yet.

I think that an issuer will only issue credentials upon request, and of a type that the issuer will have published publicly, and of which the structure is documented in that publication, which I now call a credential-type-specification. In particular, this means that the credential-type-specification specifies the structure of the graph/tree, i.e. the locations and meanings of identifiers (nodes) as well as predicates/elements/... (edges). The credential-type-specification will supply tags to identify the nodes and edges.

Using the credential-type-specification, a requester can then construct a request that specifies which portion of the graph it wants the issuer to create a credential for. Also, this request may specify a relation-statement template, e.g. of the form {id-owned-by-holder} is {issuer-node-tag} where {id-owned-by-holder} is a DID (or another identifier of which the requester can prove ownership), and {issuer-node-tag} is the tag for a node in the credential-type-specification.

When the issuer receives such a request, it can challenge the requester to prove ownership of any {id-owned-by-holder} in the request, and if the requester can do so, the issuer can include {id-owned-by-holder} is {id-owned-by-issuer} in the relation-part of the credential (that would then also contain {id-owned-by-issuer} at the designated node).

Does this make any sense?

[David-Chadwick]

@RieksJ W.r.t. 6.3, 6.4 and 6.5, and authorisations. My view is that all credentials are ultimately only needed for authorisation purposes i.e. the holder wants to achieve some goal, or access some resource etc. and therefore needs to prove to the verifier that he/she is entitled to do this. The verifier is the gatekeeper of the protected resource. A passport is only needed if you wish to travel abroad, and the the border guard is the verifier. A driving license is only needed if you wish to drive a car etc. With delegation, the subject (who possesses the authorisation via his/her VC) wishes to pass on this authorisation to someone else i.e. the delegate. So if it is an Age>18 VC that the subject uses to purchase alcohol, then by delegating this to a colleague would allow the colleague to perhaps illegally purchase alcohol. Hence the Age VC should not be delegatable. Note this does not preclude a parent from using his child's Age VC since this is not delegation, but rather Acting on Behalf of the subject. Does this answer your question?

[David-Chadwick]

@RieksJ Regarding relationships, your discourse was primarily concerned with the protocol interactions between the holder|subject and the issuer and this is clearly out of scope of the current data model document. Whilst I understand that the issuer could insert a statement in a VC to say something like belongs to if the issuer validates that the requestor possesses both IDs, I am not following your {id-owned-by-issuer} discussion as we are not interested in the relationship between the issuer and either the holder or the subject. Sorry.

[RieksJ]

@David-Chadwick: W.r.t. 6.3, 6.4 and 6.5, and authorisations. I see. It's a different perspective on the situation where access to (say) a resource needs to be protected. If you look at it from an issuer point of view, you end up with issuing permissions of some kind that should provide the access. I can see how delegation fits here. If you look at it from the gatekeeper point of view, you end up with combining attestations/attributes in some kind of reasoning that produces a a yes/no (access/no access) result.

In traditional IAM settings, issuers and gatekeepers belong to the same organization. However, with SSI, I contend that issuers and gatekeepers mostly belong to different organizations. The question is then whether or not an issuer organization, not being responsible for the gatekeeping, has any business in doing delegation.

[David-Chadwick]

@RieksJ The VC model is an open one where issuers and verifiers do not need to belong to the same organisation, though of course they can. The issuer normally would not do the delegation (although if you read my VC Lifecycle paper (https://w3c-ccg.github.io/vc-lifecycle/) you will see that the issuer can delegate the issuing of VCs to another entity. The subject would normally delegate a VC given to him/her to someone else to act on his/her behalf. E.g., I am given the the right to attend a shareholder's meeting and to vote by the company whose shares I have. The first verifier is the security guard who works for the owner of the building where the meeting is to be held. The second verifier is the software collecting the online votes. I cannot attend the meeting so I delegate to my wife to attend for me and to vote on the shareholder's resolutions.

[msporny]

We're going to leave this hanging out there for now. It's a very high level issue that will be resolved in time. After we have this latest set of updates in, we'll come back around to this issue and see if it's resolved.

[whatisthejava]

Hi, Thanks for all your hard work, I know we are late to the party but my org is looking at the verified credentials and are starting to think about implementation. We have all been around identity and distributed systems for quite a while.

While you are very specific that a subject is a thing that exists in the real world, the definition of a holder appears to change to suit the context which it is used.

Here https://www.w3.org/TR/vc-data-model/#ecosystem-overview you describe example holders in the following way "Example holders include students, employees, and customers"

This suggests that a holder is a role possibly in an organisation.

Here https://www.w3.org/TR/vc-data-model/#credential-subject-0 you describe the holder generating a signature "using a signature generated by the holder contained in the verifiable presentation"

here https://www.w3.org/TR/vc-data-model/#holder-acts-on-behalf-of-the-subject you describe the holder as the parent of the subject, this describing the holder as a thing.

And a final example in section https://www.w3.org/TR/vc-data-model/#subject-holder-relationships The image https://www.w3.org/TR/vc-data-model/diagrams/subject-ne-holder.svg is extremely clear that the holder is a thing

I think terminology around the different entities that can act as the holder based on the scenario within the section https://www.w3.org/TR/vc-data-model/#ecosystem-overview section would be useful to explain that a holder can both exist in the real world (parent, employee) or as the entity managing the signing on behalf of the subject.

I would also state, from my reading of the spec that it is unclear that a verified credential can be presented without a holder. Based on that the word might in this sentence be removed as the holder MUST exist.

A role an entity might perform by possessing one or more verifiable credentials and generating verifiable presentations from them. Example holders include students, employees, and customers.

[brentzundel]

I would also state, from my reading of the spec that it is unclear that a verified credential can be presented without a holder. Based on that the word might in this sentence be removed as the holder MUST exist.

A role an entity might perform by possessing one or more verifiable credentials and generating verifiable presentations from them. Example holders include students, employees, and customers.

The reason it says might is because not all entities, even all entities in a verifiable credential ecosystem, will necessarily be holders. Some may exclusively be issuers or verifiers. Though we imagine that most entities involved with verifiable credentials could perform any of the three roles, there is no requirement that an entity perform any one in particular.

This sentence says that if:

1. an entity possesses one or more verifiable credentials and
2. generates verifiable presentations from them,

then that entity is performing the role of a holder.

[kdenhartog]

We discussed this on the maintainence working group call and believe that this PR can be closed. If the author believes this should still be addressed it can be handled in V2 and they can reopen it.

[iherman]

The issue was discussed in a meeting on 2021-08-11

• no resolutions were taken

View the transcript

#### 4.5. On the Ecosystem Overview (issue vc-data-model#80) _See github issue [#80](https://github.com/w3c/vc-data-model/issues/80)._ > *Manu Sporny:* +1 to close **Wayne Chang:** I recommend closing this issue, there hasn't been discussion for a while and I feel that the terminology has been shaken out. Any objections to closing?