Determine interoperable way for Holder to make claims directly in VPs

[jandrieu]

VPs include a "verifiableCredential" for embedding VCs in the VP.

It's also possible to add properties to the VP that can represent claims made by the holder about the claims presented, thanks to the open world data model.

For example, in the VC Use Cases, 5.1 Citizenship by Parentage
the holder claims that he is the person born in the birth certificate, his mother is the parent in that birth certificate, that the person in the US passport is his mother, and that one of the subjects in the marriage license is his mother, all using the identifiers in those VCs to describe the relationship between the VCs.

You could of course, have the holder self-issue a VC and include in as any other VC. However, in practice, that is an unfortunate overhead, needing two signatures (the VC and the VP). It's easier just to add a property to the VP and get rid of the extra proof.

I'd like to see this standardized in some way (a candidate for v2.0). I initially considered "holderSubject" for symmetry with "credentialSubject" in the VCs. However, "holderClaims" might be more appropriate as statements about his mother have a different subject.

In a very pseudocode example:

"holderClaims": [{ 
  "id":"did:example.com:mom",
  "sameAs": [
    "did:example.com:momInBirthCertificate",
    "did:example.com:momInMarriageLicense",
    "did:example.com:momInPassport",
   ]
  "parentOf": "did:example.com:holder"
}]

[jandrieu]

Discussed on WG call 2022.08.24.
https://www.w3.org/2022/08/24-vcwg-minutes.html

@msporny and @dlongley advocated for sticking with the use of VCs rather than supporting a different way to make claims.

@jandrieu Suggested that unless we change the open-world data model of the VP itself, this behavior "holderClaims" as a property in the VP is allowed, and as such, is likely be used by developers who find it to be a more convenient solution. I could support a debate about moving away from an open world model (and considering restricting this practice), but if we stay with the current spec, which allows arbitrary properties in the VP, then standardizing the use would increase interoperability.

Note that if a developer wants to stick with the VC-based approach, a standard property for holder asserted claims, such as "holderClaims" would not prevent that approach. However, today, the only interoperable option requires duplicate signatures and duplicate verifications. In some use cases, the additional cryptography is more of a burden than justified, e.g., in IOT devices where computation and data size are both at a premium.

Kristina mentioned there is support for this use case and recommended we leave the conversation open for people to consider.

No resolutions made.

[agropper]

This is close to the user-centric authorization request we use for sharing health records. Along with credentials, the signed presentation includes a claim of purpose as well as the scope of the request. Our use-case helps focus the question of open world vs. interop.

Every request has three orthogonal dimensions:

• the credentials of the requesting party (claims that are signed by others)
• the purpose of the request (claims that are signed by the requesting party themselves)
• the scope of the authorization or transaction requested (description of the transaction to be authorized)

RAR is one relevant aspect of this conversation.

[agropper]

I wonder how the "User-Centric Request Model" (UCRM) perspective fits into this discussion. Briefly, UCRM, assumes that one or more VCs are combined with a stated purpose and scope of a transaction resulting in a capability / authorization for the transaction. The party signing the request is held accountable based on their signature on the request. Aside from the VCs presented, interoperability of scope seems pretty trivial since asking for a resource or scope that is not understood by the verifier is guaranteed to fail even before validating other aspects of the request. That leaves interoperability of purpose specification which is probably out of scope for this WG except as it relates to open world schemas and contexts. I'm hoping that this UCRM use-case helps drive consensus around the presentation of VCs.

…

On Wed, Aug 24, 2022 at 11:57 AM Joe Andrieu ***@***.***> wrote: Discussed on WG call 2022.08.24. @msporny <https://github.com/msporny> and @dlongley <https://github.com/dlongley> advocated for sticking with the use of VCs rather than supporting a different way to make claims. @jandrieu <https://github.com/jandrieu> Suggested that unless we change the open-world data model of the VP itself, this behavior "holderClaims" as a property in the VP is allowed, and as such, is likely be used by developers who find it to be a more convenient solution. I could support a debate about moving away from an open world model (and considering restricting this practice), but if we stay with the current spec, which allows arbitrary properties in the VP, then standardizing the use would increase interoperability. Note that if a developer wants to stick with the VC-based approach, a standard property for holder asserted claims, such as "holderClaims" would not prevent that approach. However, today, the only interoperable option requires duplicate signatures and duplicate verifications. In some use cases, the additional cryptography is more of a burden than justified, e.g., in IOT devices where computation and data size are both at a premium. Kristina mentioned there is support for this use case and recommended we leave the conversation open for people to consider. No resolutions made. — Reply to this email directly, view it on GitHub <#860 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YMLAKCY367TJR4SDBDV2ZBADANCNFSM5LZ7BVBA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[iherman]

The issue was discussed in a meeting on 2022-12-14

• no resolutions were taken

View the transcript

5.3. Determine interoperable way for Holder to make claims directly in VPs (issue vc-data-model#860)

See github issue vc-data-model#860.

Joe: had in credential the issuer issued a mDL but nothing about the subject presenting the credential. Is the current presenter the same as the issuer gave the VC to use case individual claiming US citizenship, the birth certificate claims the relationship to his mother, but she's remarried and has changed her name. Need something to connect these changes. This is me; this is my boss, my child, or simply I found this vc.
… how do we have a standard way to represent these complicated semantic relationships? Having one would be helpful.

Phillip Long: Kristina - perhaps we should think about this though this issue has been opened back in Jan this year.

Manu Sporny: we should think more about this and provide a standard mechanism for representing this relationships.
… we need concrete guidance for people who want to put these properties in the representation. It could be come a big conversation. We've only had a terms of use in a presentation to date..
… we'll need to approach this from a "use cases first" perspective..
… need to be very specific about the use cases..

Dmitri Zagidulin: +1 to re-using existing VC primitive, vs introducing a new primitive of adding claims to VP.

Dave: we should try to leverage the primitives we already have. One way to do that is the VC. Given there is a lot complicated relationships and not have a highly complex reasoning engine to process it we should leverage VCs where the kinds of relationships are modeled. EG. give a parent child assertion yourself offered..

Dave Longley: +1 to being able to say anything -- but there's a need for the verifier to know what they are saying as well, +1 to common vocabs and an easy way for the verifier to say what they will understand in the first place..

Joe: a little confused by what Dave just said. VCs require a separate artifact and different from the flow. Should be an action of the presentation. This is still "openworld" - should express this with some constrained openworld. Need a vocab that expresses common relationships. Good to address nontransferrable property, etc. would help us get rid of babel problem but need to express things as the real world works..

Kristina Yasuda: let's leave this conversation for further thought. Happy New Year for everyone. We've made progress with new V2 WG and working on it..

---

[iherman]

The issue was discussed in a meeting on 2023-02-08

• no resolutions were taken

View the transcript

4.3. Determine interoperable way for Holder to make claims directly in VPs (issue vc-data-model#860)

See github issue vc-data-model#860.

Brent Zundel: determine interoperable way to make claims directly in VPs.
… joe raised issue.

Joe Andrieu: not much convo back and forth. Last time there was some pushback on call.
… tension is do we want to reuse the VC and require a second sig.
… or is there a way to use a property in the VP and let signer put some assertions in there.
… manu and dave thought VC approach better.

Manu Sporny: concern is that we have primitive already. That is the VC.

Dave Longley: +1 to reusing the primitive we have already and using composition.

Manu Sporny: can we compose it. VC allows us to say anything about anyone.
… Additional VC could contain any of the additional contents that an additional property might contain.
… is true that it would be an additional thing to be issued and signed.
… suggested property will eventually become a VC. Why not just use a vc.

Joe Andrieu: separate VC need a way to bind to a VP.
… a way to say that this VC is specifically about a VP when it is presented.
… semantics should be part of a VP added when VP is created.

Brent Zundel: how terrible would it be to have property in VP. But specify that the value of that property would be a VC.

Dave Longley: +1 to what brent said being an option, was having the same thought.

Brent Zundel: so property in VP would be in form of a VC.

Manu Sporny: its a good though. I had similar. It is a way of doing this. Still thinking about it.
… raises Q of why we need an additional property in VP to do that.
… if the VC is in the VP then it is already bound to VP. Its all bound together.
… Key thing is lets reuse primitives we already have.
… Just need to address the binding concern.

Michael Prorock: Going the same direction as brent. Feels like a vocab problem.
… handling this in supply chain traceability. Extended the type on VC to TraceableVC..
… this enables linking of VCs together.
… if the vocab and data models give us ability to define these things for use cases. Lets do that for those use cases.
… not reinvent the wheel.

Orie Steele: DIF also extends the RDF type for "VerifiablePresentation"... https://identity.foundation/presentation-exchange/#presentation-submission---verifiable-presentation-2.

Manu Sporny: +1 to mprorock, we need to have a specific use case someone is building out for to apply this to.

Michael Prorock: The tools we need exist.

Joe Andrieu: I like idea of property whose values are credentials. Push back on making the VCs.
… want to avoid the need for multiple vcs.
… if we have multiple VCs in a presentation. Which VC defines the semantics of the presentation.
… trying to figure out and standardise that.

Michael Prorock: the presentation type does that, not the credentials in it.

Joe Andrieu: semantics of VP are about why is this thing being presented and by whom.

Orie Steele: VP has only 2 requirements... context and type..

Brent Zundel: don't have normatively defined way to sign and secure a VP..
… Might this be a way to bind a VP to the presenter.

Orie Steele: https://w3c.github.io/vc-data-model/#presentations-0 see the requirements..

Manu Sporny: https://w3c-ccg.github.io/vp-request-spec/#did-authentication.

Manu Sporny: data integrity work covers embedded proofs for presentations.
… also a VP request spec that talks to this.
… concern is that some people would think we are now defining protocols. Growth of scope.

Michael Prorock: +1 manu.

Manu Sporny: hard to talk about presentations without going into protocols.

Orie Steele: OIDC has ways of doing this as well, perhaps someone can cite those items for the minutes as well?.

Manu Sporny: agree with mprorock. For us to say this is applicable and useful need to see use cases in the field and then standardise from that.
… find commonalities instead of generalise too early.

Michael Prorock: I agree with manu.

Orie Steele: For the minutes: https://openid.net/specs/openid-4-verifiable-presentations-1_0.html.

Michael Prorock: when you start to get into practicalities, start going into protocols..
… many of this issues we are correcting and improving in vc data model spec are down to how we thought something would/does work in the wild.
… against adding additional complexity, rather that seeing what happens in implementations.

Joe Andrieu: frustrated to deference to implementations.
… we have use cases in the use case document that have requirements from start.

Michael Prorock: then define a vocab.

Joe Andrieu: The semantics of what the presentations means is the gap.
… we have use cases that we haven't been able to address currently because of this.
… Need to define semantics of a VP.

Orie Steele: joe is getting at 2 possible world views.
… 1 - purely the responsiblity of the data model. Almost what we have today. Clear that protocols will extend using @context and type to support there use cases.
… Because it landed like this in 1.1. people are deferring to protocol.
… also concerned about getting into protocols in this WG.
… Feel protocols are adding many more requirements to VPs.
… concerned about VPs in there current form in the spec.

Michael Prorock: agree, there are things we need to improve about VPs in spec. Not sure this is one of them.
… Deal with gov and regulatory folks. They are relatively happy with it the way it is.
… worried about getting pulled off on tangents.

David Chadwick: I support JoeAndrieu's view.
… This is about holder or presenter telling the verifier about the contents of the VP and how they should handle them.

Michael Prorock: "type".

David Chadwick: likely something about holder binding too. Proof of possession.
… Think we do need to broaden the data model for VPs in a standard way.
… if do it for your own applications then you are doing it in a non standard way.

Kerri Lemoie: Part of the confusion with VPs in the ecosystems that VPs are used for things other than presenting VCs.

Mahmoud Alkhraishi: Have similar problem with the issuer field.
… Not very clear to me who gets to define the values in the issuer field and what it looks like.
… don't want to derail this convo, but tangentially related.
… suggest extend VP the same way as the traceability vocab.

Manu Sporny: agree with mkhraisha.
… would help me to understand concretely what the solns look like.
… we have extensibility model. Nothing to stop anyone creating an extension to solve use cases that JoeAndrieu is talking about.
… suggest we should do this to create something concrete we can look art.

Orie Steele: RDF is the extensibility model for Verifiable Presentations... context and type... that is it..

Orie Steele: We've seen several use cases of vocabularies doing this today..

Juan Caballero: (not too much less ambitious).

[TallTed]

@iherman — Please edit your #860 (comment) and code fence the now-bare @context, changing it to `@context`, so that GitHub user is not dragged into our conversations. This likely should be done in myriad other meeting transcripts...

[Sakurann]

You could of course, have the holder self-issue a VC and include in as any other VC. However, in practice, that is an unfortunate overhead, needing two signatures (the VC and the VP). It's easier just to add a property to the VP and get rid of the extra proof.

I understand the need for self-attested claims, and I think we can do it without defining anything new by providing guidance that "to make claims, the Holder should create a self-signed VC and send it as a VC, without a VP (hence without double signing).

[iherman]

The issue was discussed in a meeting on 2023-04-11

• no resolutions were taken

View the transcript

1.1. Determine interoperable way for Holder to make claims directly in VPs (issue vc-data-model#860)

See github issue vc-data-model#860.

Kristina Yasuda: "Determine interoperable way for Holder to make claims directly in VPs".
… opened by Joe.
… currently labeled discuss.

Joe Andrieu: The notion of this issue is that right now the only way to handle this is for holders to extend the model on their own, but no interoperable and normative way. also possible to embed a VC, but no standard way of having a VC referencing a VP.
… thought was to add a property to the VP like "holder claims" to attach this in and sign it just like you do normally.

Kristina Yasuda: question for this call - is there a resolution, or an assignment to take it on.

Joe Andrieu: volunteers to take the issue on.

[iherman]

The issue was discussed in a meeting on 2023-04-11

• no resolutions were taken

View the transcript

1.1. Determine interoperable way for Holder to make claims directly in VPs (issue vc-data-model#860)

See github issue vc-data-model#860.

Kristina Yasuda: "Determine interoperable way for Holder to make claims directly in VPs".
… opened by Joe.
… currently labeled discuss.

Joe Andrieu: The notion of this issue is that right now the only way to handle this is for holders to extend the model on their own, but no interoperable and normative way. also possible to embed a VC, but no standard way of having a VC referencing a VP.
… thought was to add a property to the VP like "holder claims" to attach this in and sign it just like you do normally.

Kristina Yasuda: question for this call - is there a resolution, or an assignment to take it on.

Joe Andrieu: volunteers to take the issue on.

[Sakurann]

"pending-close" unless DavidC's presentation will be an inspiration.

[David-Chadwick]

I had a similar proposal to this which I wanted to present at the last face to face but there was insufficient time. However the slides are still publicly available here
https://www.w3.org/2017/vc/WG/Meetings/F2F/VCWG_Miami_F2F_2023.pdf
See Day 1, immediately after the Holder Binding presentation, slides begin with the title Alt Holder Binding. The slides define a property X (which is similar in concept to @jandrieu holderClaims, but X was made extensible by having a type and then any additional properties required for that type. i.e.

{
	"x": [{
		"credentialId": "id of an embedded VC",
		"type": "a URI",
		"other optional properties": "as defined by the type"
	}]
}

@jandrieu I think you can see how the above generalises your proposal. We could then add to the directory specific values of the URI to mean specific things e.g. relative, bearer, issuee, subject etc. I give various examples in my slide set

[David-Chadwick]

P.S. I don't really care what name we give to property X as it is the concept that is the most important thing. I have suggested verficationHints which I think neatly summarises its purpose. But holderClaims also imparts the concept that the holder is claiming something that the verifier can use to help it sort out and verify the set of VCs that the holder is presenting.

[iherman]

The issue was discussed in a meeting on 2023-06-14

• no resolutions were taken

View the transcript

2.3. Determine interoperable way for Holder to make claims directly in VPs (issue vc-data-model#860)

See github issue vc-data-model#860.

Joe Andrieu: I think we don't have 2 implementations of this.
… will other people implement this.
… this issue requests definition for a property about other properties.
… there is a use case for requesting citizenship documents by providing suplemental credentials.
… bascially repeat the concept of credentialSubject for holderClaims...
… there is some conversation on it, I think you can always use an unsigned vC.

Orie Steele: Just a comment on normative requirements, proof is optional, party can include additional fields by relying on JSON-LD context, you don't need two independent implementations to achieve this, you can use reserved terms, if W3C doesn't reserve terms, won't matter in context of standards, if govt. processing, they determine those terms.

David Chadwick: I noticed a similar requirement a couple months ago, but we never presented at the face to face.
… I will point to the definition we had for this feature.
… I have defined examples, maybe we have the same idea, take a look at the slides.
… the slides are follow on related to holder binding.

Dave Longley: seems like the verifier won't accept arbitrary properties.
… seems like an additional credential use case.
… where the holder issuers a self asserted credential.
… and then the verifier will process self signed credentials from the holder wallet.

Michael Jones: I approved status-list PR #46 with w3c/vc-bitstring-status-list#46 (review).

Dave Longley: i think we have the tools to make this happen, we don't need new reserved W3C terms.

Kristina Yasuda: maybe leave a comment regarding the proposed paths forward.

Joe: DavidC can you leave a comment on the issue, unless there is something to fight for, we should close it.

Kristina Yasuda: thanks all.

David Chadwick: see https://www.w3.org/2017/vc/WG/Meetings/F2F/VCWG_Miami_F2F_2023.pdf.

Kristina Yasuda: please review PRs and issues outside of call time.
… next week's special topic call will be status list codes, or 1100 1101 PRs regarding mapping and content types.

David Chadwick: Slides are titled Alt Holder Binding.

---

[jandrieu]

I'm warming up to @Sakurann's proposal, if we can find normative language to add to the spec.

Something like

In the case where an entry in the verifiableCredential property of a Verifiable Presentation does not include a proof, but the Verifiable Presentation does, then those entries are understood to be claims made by the creator of the Verifiable Presentation. Their content integrity is assured by the Verifiable Presentation's proof.

That seems like a workable direction, but I'm not fluent enough in the JWT work to understand if that works for VP-JWTs or the equivalent.

Is that where you were headed @Sakurann?

[Sakurann]

What is the difference between a self-signed a VP with an unsigned VC versus a self-signed VC?

[David-Chadwick]

There is a difference in approach based on the hierarchical level at which the holder's assertions are placed. These assertions could be placed at the VP level, and relate to the VCs in the verifiableCredential property, or they could be in a separate (unsigned) VC along with the other VCs to which it relates. In my view turning these assertions into an unsigned VC introduces extra baggage that is not needed if they are placed at the VP level, since the VP already includes the extra baggage of validFrom, validUntil, type, issuer etc.

[agropper]

Indeed. The requesting party (aka “holder”) must be held responsible for the totality and context of their request. That includes Purpose as well as Scope as well as any VCs and possibly a Deposit to offset processing costs. Therefore the RqP must sign the request itself.

…

On Thu, Jun 15, 2023 at 5:12 AM David Chadwick ***@***.***> wrote: There is a difference in approach based on the hierarchical level at which the holder's assertions are placed. These assertions could be placed at the VP level, and relate to the VCs in the verifiableCredential property, or they could be in a separate (unsigned) VC along with the other VCs to which it relates. In my view turning these assertions into an unsigned VC introduces extra baggage that is not needed if they are placed at the VP level, since the VP already includes the extra baggage of validFrom, validUntil, type, issuer etc. — Reply to this email directly, view it on GitHub <#860 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YLRRXLHXPRBEKGV7E3XLLGYBANCNFSM5LZ7BVBA> . You are receiving this because you commented.Message ID: ***@***.***>

[brentzundel]

What is the difference between a self-signed a VP with an unsigned VC versus a self-signed VC?

I'm not sure there is much of a difference, but a self-signed VC would allow an implementer to avoid having to create a separate flow to account for both signed and unsigned VCs in a VP.

[agropper]

Makes sense. Which is why the one flow to use VCs that bears standardization is Request (as specified by IETF GNAP) instead of VP.

…

On Thu, Jun 22, 2023 at 12:13 PM Brent Zundel ***@***.***> wrote: What is the difference between a self-signed a VP with an unsigned VC versus a self-signed VC? I'm not sure there is much of a difference, but a self-signed VC would allow an implementer to avoid having to create a separate flow to account for both signed and unsigned VCs in a VP. — Reply to this email directly, view it on GitHub <#860 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YMT3QHJVU4TO6QC57TXMRVI5ANCNFSM5LZ7BVBA> . You are receiving this because you commented.Message ID: ***@***.***>

[OR13]

#1181

[iherman]

The issue was discussed in a meeting on 2023-07-05

• no resolutions were taken

View the transcript

2.6. Determine interoperable way for Holder to make claims directly in VPs (issue vc-data-model#860)

See github issue vc-data-model#860.

Kristina Yasuda: This is about self-signed VCs, right?

Orie Steele: Brent has a raised a PR that addresses a lot of this issue.
… Pull 1181.
… PR 1181 doesn't currently reflect what you can do with a VP.
… Brent, can you please revise per the comments.

See github pull request vc-data-model#1181.

Orie Steele: it could address that issue.

Brent Zundel: I don't remember if I tried to address the comments or not yet, but I definitely can.

Kristina Yasuda: I've assigned this to you, Brent.

Joe Andrieu: present?

[brentzundel]

@jandrieu I've attempted a PR #1186 to address this issue and would appreciate feedback from you on it

[iherman]

The issue was discussed in a meeting on 2023-07-11

• no resolutions were taken

View the transcript

1.9. Add interoperable way for holder-asserted claims in a VP (pr vc-data-model#1186)

See github pull request vc-data-model#1186.

Brent Zundel: P.R seeks to address issue #860.
… provides normative guidance for holder claims in a presentation.
… a holder can elect to either produce a VC secured on its own and insert into vc array of the presentation.

See github issue vc-data-model#860.

Brent Zundel: alternatively they can include an unsecured VC in the presented vcs.
… as long as issuer field of the VC and the holder field of the presentation match. Then the issuer can have confidence that this is self attested claim from the holder.
… all comments have been responded to. Awaiting final review from TallTed.
… open to comments.

Phillip Long: +1 to that PR pertains to issue 860.

Andres Uribe: made a comment about enabling forwarding of credentials.
… not sure how that would be possible using the self asserted type.
… maybe this isn't a use case that is as important to support.

Oliver Terbu: can see interop issues with this approach in the future.
… many other ways to achieve the same. Are we saying this is the only approach to achieve this.
… not sure this is the right approach. Not objecting, just a comment.

Dave Longley: think forwarding use case can be solved by attaching a signature to the VC.
… using a SelfAsserted type is just a recommendation.
… think P.R is really around enabling the VP to be the securing for self attested claims.
… otherwise holder can just act in the role of issuer.
… this adds a mechanism to secure using proof of the VP itself.

Joe Andrieu: part of this shift has missed some of initial point from issue #860.
… this was about how you say these claims are about this specific thing right now.

Dave Longley: perhaps give the VP an ID and include that in your VC claims.

Joe Andrieu: not sure how we address that.

Will Abramson: PL-ASU: this is in relation to the self asserted. The fact that there may be a circumstance where self-asserted claims do not want them to be forwarded.

Oliver Terbu: I heard that we have two different issues.
… JoeAndrieu wanted author of credentials about the VP and the ability to include those in a presentation.
… then there is the one about self asserted with proof from the VP used to secure.
… maybe we need separate P.Rs for this.

Brent Zundel: any concrete proposals or changes to this P.R is appreciated. Not sure how to act on the general guidance.
… responding to JoeAndrieu, should be easy to add a line to the spec that addresses your use case.

Joe Andrieu: think that is pretty good. E.g. if it says if you are making a VP, you could have the ID of a VP that you then refer to.

Brent Zundel: okay I can make that change.

[iherman]

The issue was discussed in a meeting on 2023-07-11

• no resolutions were taken

View the transcript

1.9. Add interoperable way for holder-asserted claims in a VP (pr vc-data-model#1186)

See github pull request vc-data-model#1186.

Brent Zundel: P.R seeks to address issue #860.
… provides normative guidance for holder claims in a presentation.
… a holder can elect to either produce a VC secured on its own and insert into vc array of the presentation.

See github issue vc-data-model#860.

Brent Zundel: alternatively they can include an unsecured VC in the presented vcs.
… as long as issuer field of the VC and the holder field of the presentation match. Then the issuer can have confidence that this is self attested claim from the holder.
… all comments have been responded to. Awaiting final review from TallTed.
… open to comments.

Phillip Long: +1 to that PR pertains to issue 860.

Andres Uribe: made a comment about enabling forwarding of credentials.
… not sure how that would be possible using the self asserted type.
… maybe this isn't a use case that is as important to support.

Oliver Terbu: can see interop issues with this approach in the future.
… many other ways to achieve the same. Are we saying this is the only approach to achieve this.
… not sure this is the right approach. Not objecting, just a comment.

Dave Longley: think forwarding use case can be solved by attaching a signature to the VC.
… using a SelfAsserted type is just a recommendation.
… think P.R is really around enabling the VP to be the securing for self attested claims.
… otherwise holder can just act in the role of issuer.
… this adds a mechanism to secure using proof of the VP itself.

Joe Andrieu: part of this shift has missed some of initial point from issue #860.
… this was about how you say these claims are about this specific thing right now.

Dave Longley: perhaps give the VP an ID and include that in your VC claims.

Joe Andrieu: not sure how we address that.

Will Abramson: PL-ASU: this is in relation to the self asserted. The fact that there may be a circumstance where self-asserted claims do not want them to be forwarded.

Oliver Terbu: I heard that we have two different issues.
… JoeAndrieu wanted author of credentials about the VP and the ability to include those in a presentation.
… then there is the one about self asserted with proof from the VP used to secure.
… maybe we need separate P.Rs for this.

Brent Zundel: any concrete proposals or changes to this P.R is appreciated. Not sure how to act on the general guidance.
… responding to JoeAndrieu, should be easy to add a line to the spec that addresses your use case.

Joe Andrieu: think that is pretty good. E.g. if it says if you are making a VP, you could have the ID of a VP that you then refer to.

Brent Zundel: okay I can make that change.

[msporny]

@jandrieu, did PR #1186 address your concern, and if so, can we close this issue?

[brentzundel]

PR #1186 was raised to address this issue and has been merged. Closing in 7 days if no objections are raised.