vc-data-model
vc-data-model copied to clipboard
w3c
Authorized Presenters
We are running into a use case where require a credential to be presented by an issuer, or other set of parties known at issuance time. Currently, we do not have a way to express this in the VC a list of "authorized presenters."
I know this is related to confidence method and binding work.
I am not sure if there's enough demand to get a spec change in (unless there is - chime in!), so I'm mostly curious how others are solving this problem. Solutions that involve additional "relationship credentials" seem too complex.
SD-JWT uses cnf for this already.
If Data Integrity wants to do it differently, that seems like something for the data integrity spec to specify.
Doing this at the securing mechanism layer is probably the wrong thing to do. Additional semantics are useful when building confidence on alternate parties that might present a credential.
[@OR13] SD-JWT uses
cnffor this already.
It would be helpful if you could to link to the SD-JWT RFC section that covers this.
@TallTed
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-06#section-5.1.2
But beware there are open PRs related:
- https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/394
Marking as post-CR, open to pending-close unless others think adding this type of guidance is useful for v2.
The issue was discussed in a meeting on 2023-12-06
- no resolutions were taken
View the transcript
2.3. Authorized Presenters (issue vc-data-model#1359)
See github issue vc-data-model#1359.
Gabe Cohen: I would like to explore the question of who is authorized to present a credential. I recollect that we discussed this in the past but did not come up with a solution. I would be interested to know what others are doing in this regard.
Dave Longley: +1 that more semantics are needed and should use confidence method.
Manu Sporny: Digital Bazaar aren't doing this. I imagine that ConfidenceMethod would meet this requirement.
Orie Steele: SD-JWT currently requires you to do this in a special way: you are required to implement support for Confirmation Method, which is the IETF way of doing this.
… If ConfidenceMethod was in the core model, there might be conflicting or redundant ways to express this.
… This is built-in to SD-JWT, so we can't contradict what's already the case in SD-JWT's specification.
Orie Steele: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-06#section-5.1.2.
Dave Longley: to say i'm not sure what SD-JWT does, but i would not expect
cnfto cover this use case, more semantics are needed.
Dmitri Zagidulin: The CNF property used to identify the current presenter in SD-JWT, not to list authorized presenters - is this correct ?
Gabe Cohen: sd-jwt-vc has cnf as well https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-01.html.
Orie Steele: We've updated the specification so that won't be up to date any longer.
Orie Steele: also, sd-jwt is still a wg adopted draft.... so... this might all change.
Dmitri Zagidulin:
@Orie- looking at https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-01.html , I still see no wording on how an issuer specifies authorized presenters. Only wording on how to use cnf in the DPoP sense.
Orie Steele: not correct summary of what SD-JWT....
David Chadwick: I think it's probably a bit different with SD-JWT, because the issuer is given unblinded data to a specific entry. Anyone else who gets the credential will be blind to who is presenting it. What the SD-JWT does is 'blind' data, but makes disclosures in the clear. The holder is getting the information in the clear.
… It's not the same as normal Verifiable Credentials because only Holders are able to see the unblinded data. Therefore only the holder is able to present it.
Orie Steele: dmitriz, I am not talking about that draft, I am talking about https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-06#section-5.1.2.
Dmitri Zagidulin:
@Orie- got it, thanks.
Orie Steele: I acknowledge the authors of draft oauth-sd-jwt-vc have a lot of work still to do : ).
Dmitri Zagidulin:
@Oriein draft 06, it seems like it's using the 'cnf' property in a way that's not intended by the DPoP rfc, it should probably be the 'aud' claim. But anyways, that's a discussion for the ietf spec.
Dave Longley:
@dmitriz: yup, also note that the current SD-JWT mechanism does not say which person thecnfclaims applies to (for multiple holders, etc.).
Orie Steele: We have an entire TR track document.
Brent Zundel: Did that help, decentralgabe?
Gabe Cohen: A little; I'm happy for it to be closed now.
Brent Zundel: I'll leave this to you decentralgabe.
The issuee property partially solves this issue, because it is highly improbable that an issuer would issue a VC to an entity (the issuee) who was not entitled to present it. So by defining the issuee property you already have a partial solution. As to providing a solution for a completely different third party (i.e. not the issuer, not the issuee nor the subject) being authorised to present it, the question is, even if the issuer knows who this third party is, how did this third party get the VC in the first place? One solution is for this third party to request the VC from the issuer, and for its identity to be inserted into the issuee property. Then you have a complete solution to your problem. Another alternative is for the third party to request the VC from the issuee, but this pre-supposes that the issuee knows who the set of authorised presenters are. And that may not be feasible in all situations, nor even desirable. So assuming that the issuer is the only entity that knows who the authorised presenters are, I suggest the simplest solution is for each of these entities to ask the issuer for the VC, and to have their identity inserted into the issuee property.
even if the issuer knows who this third party is, how did this third party get the VC in the first place
there are cases like a parent presenting on behalf of their child, or even an individual who has migrated to a new identifier that wishes to present their credential
I suggest the simplest solution is for each of these entities to ask the issuer for the VC, and to have their identity inserted into the issuee property.
I agree this is simplest and while not ideal (it will cause friction and assumes interoperable protocols) we should probably add some text like this
Issue #942 suggested adding the issuee property, so that it is standardised and will minimise interoperability problems (which would happen if each issuer defined its own issuee property). @decentralgabe Would you like to suggest re-opening this issue?
@David-Chadwick personally I think there is value in doing that, but given the long discussion, and pushback in #942 I am not sure we will end up with a different result. May be worth briefly discussing this on an upcoming call (cc: @brentzundel).
I'm curious what the PR will be.
My general disposition is that VCs should not present an information control system, aka DRM, which is what we get if we allow issuers to dictate who is allowed to share a VC.
I missed the chance to mention this on the call today, but I would strongly oppose changes to the spec, normative or otherwise, that suggests issuers have any legitimate authority to restrict what information a holder shares, including the VCs that they have in their position.
IMO, the right nuance of this is addressed with the confidence method, in which issuers indicate how a verifier might establish confidence that the subject of a claim in a VC is interacting with them in some way.
I agree in theory @jandrieu but with confidence method in its current (lackluster) state I view this as a gap worth adding some language to. I welcome your suggestions and wordsmithing help. I do not want to suggest that an issuer can restrict, but instead, allow certain authorized presenters explicitly.
The issue was discussed in a meeting on 2024-03-06
- no resolutions were taken
View the transcript
2.3. Authorized Presenters (issue vc-data-model#1359)
See github issue vc-data-model#1359.
Brent Zundel: 1359.
… decentralgabe this is assigned to you.
Gabe Cohen: I still think it'd be helpful for this to be described in the spec.
… when you're going to make a VP, how can you be sure that the entity presenting it is authorized to present it.
… so we avoid anyone presenting it to anyone.
Manu Sporny: +1. I do think we can point to the confidence method spec.
… the only concern I have is that the spec hasn't been touched in awhile.
… I do think we plan to revisit it in a future WG, but not sure we want to talk about it before then.
Ted Thibodeau Jr.: having a VC property for "authorized presenters" seems a fine extension, but what to do with it feels like business logic.
Manu Sporny: we could talk about matching DIDs and comparing crypto related to those at each layer.
… it's really when you want to connect it to a additional binding mechanisms that you'd want confidence method to come in.
Brent Zundel: a full treatment of this seems too much to handle right now.
Manu Sporny: I agree with Brent's overall analysis. What can we do editorially for this?
Brent Zundel: what aspect of this would fit right now, is my question to decentralgabe.
… we've got general interest in closing this, but we should narrow in on a specific recommendation.
Gabe Cohen: I'd like to see non-normative text about it that could later be made normative.
… it would at least help nudge people toward the future.
Brent Zundel: is this something you can do?
Gabe Cohen: yes, but it's lower priority.
Brent Zundel: I will note you assigned it to yourself in December, and it's still yours to do.
Ted Thibodeau Jr.: I'm still very unclear how confidence method applies to who's presenting.
… it does feel reasonable to say "these are my authorized presenters", but how to enforce that feels like business logic to me.
Manu Sporny: I agree with Ted's analysis.
Gabe Cohen: will attempt some language, looking forward to it being torn apart :).
Michael Jones: how do you see this list interacting with proof of possession binding?
Gabe Cohen: that's one option, but there be situations where that's not present.
Michael Jones: just wanted to note they were related.
Sorry I missed the meeting on 6 March, but I was travelling. @jandrieu
if we allow issuers to dictate who is allowed to share a VC.
Adding an issuee property to a VC is not saying anything about who is allowed to share a VC. It is simply stating a fact about who the issuer issued the VC to. The current holder or verifier can process this data is whatever way they wish to.
@decentralgabe I agree with you that the confidence method is not likely to solve your problem anytime soon.
[@David-Chadwick] Adding an issuee property
Note that this issue (#1359) is about adding a property for "authorized presenters", which is not an "issuee" property.
Correct, but it can double up for that if the verifier wants to do so
The issue was discussed in a meeting on 2024-03-27
- no resolutions were taken
View the transcript
3.2. Authorized Presenters (issue vc-data-model#1359)
See github issue vc-data-model#1359.
David Chadwick: The issuee property is one potential, at least semi-solution to this, it's also a solution to this. It's also a solution to some of the text in the status list PRs.
… Someone suggested we replace issuee as firstHolder but we should just call it issuee.
Manu Sporny: Here's where it was injected: https://w3c.github.io/vc-data-model/#reserved-extension-points.
Manu Sporny: I dont disagree with what DavidC and TallTed said.
… but do we really want to define it.
Ted Thibodeau Jr.: I suggested that someone create a new issue for this along with appropriate PRs where it should be inserted.
Manu Sporny: +1 to TallTed's suggestion, for those that want "issuee".
David Chadwick: I dont think that adding a definition for issuee is a normative change for implementations.
I think issuee(s) is insufficient for authorizedPresenter(s). (I think both of these should be singular as property names, though they should not be limited to single values.)
I think an implementation extension (i.e., not directly handled within our spec) might be the best way to handle authorizedPresenters, at present.
Yes I agree. We said at our WG meeting that introducing the definition of issuee should not make any normative changes to VCDM. So any use of the issuee role should be done in an extension document and added to the directory of extensions.
There is not consensus to add an authorized presenter role or capability to the VCDM at this point.
The conversation around whether to add an Issuee role and the extent to which there may be consensus to do so is being discussed in #1467
I am closing this issue.
