Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Authorized Presenters #1359

Closed
decentralgabe opened this issue Nov 20, 2023 · 22 comments
Closed

Authorized Presenters #1359

decentralgabe opened this issue Nov 20, 2023 · 22 comments
Assignees
Labels
discuss pending close Close if no objection within 7 days post-CR ready for PR This issue is ready for a Pull Request to be created to resolve it

Comments

@decentralgabe
Copy link
Contributor

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.

@OR13
Copy link
Contributor

OR13 commented Dec 6, 2023

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.

@msporny
Copy link
Member

msporny commented Dec 6, 2023

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.

@TallTed
Copy link
Member

TallTed commented Dec 6, 2023

[@OR13] SD-JWT uses cnf for this already.

It would be helpful if you could to link to the SD-JWT RFC section that covers this.

@OR13
Copy link
Contributor

OR13 commented Dec 6, 2023

@decentralgabe
Copy link
Contributor Author

Marking as post-CR, open to pending-close unless others think adding this type of guidance is useful for v2.

@iherman
Copy link
Member

iherman commented Dec 7, 2023

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 cnf to 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: @Orie in 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 the cnf claims 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.

@decentralgabe decentralgabe self-assigned this Dec 11, 2023
@David-Chadwick
Copy link
Contributor

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.

@decentralgabe
Copy link
Contributor Author

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

@David-Chadwick
Copy link
Contributor

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?

@decentralgabe
Copy link
Contributor Author

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

@decentralgabe
Copy link
Contributor Author

Related to w3c/vc-jose-cose#242

@decentralgabe decentralgabe added the ready for PR This issue is ready for a Pull Request to be created to resolve it label Mar 6, 2024
@jandrieu
Copy link
Contributor

jandrieu commented Mar 6, 2024

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.

@decentralgabe
Copy link
Contributor Author

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.

@iherman
Copy link
Member

iherman commented Mar 6, 2024

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.

@David-Chadwick
Copy link
Contributor

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.

@David-Chadwick
Copy link
Contributor

@decentralgabe I agree with you that the confidence method is not likely to solve your problem anytime soon.

@TallTed
Copy link
Member

TallTed commented Mar 13, 2024

[@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.

@David-Chadwick
Copy link
Contributor

Correct, but it can double up for that if the verifier wants to do so

@iherman iherman added the pending close Close if no objection within 7 days label Mar 27, 2024
@iherman
Copy link
Member

iherman commented Mar 27, 2024

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.

@TallTed
Copy link
Member

TallTed commented Mar 28, 2024

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.

@David-Chadwick
Copy link
Contributor

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.

@brentzundel
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss pending close Close if no objection within 7 days post-CR ready for PR This issue is ready for a Pull Request to be created to resolve it
Projects
None yet
Development

No branches or pull requests

8 participants