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

Fix media type registration language #1052

Closed
msporny opened this issue Feb 20, 2023 · 5 comments
Closed

Fix media type registration language #1052

msporny opened this issue Feb 20, 2023 · 5 comments
Assignees
Labels
editorial Purely editorial changes to the specification. media-type pending close Close if no objection within 7 days ready for PR This issue is ready for a Pull Request to be created to resolve it

Comments

@msporny
Copy link
Member

msporny commented Feb 20, 2023

The media type registration language in the current specification is a bit wonky. It says:

This specification registers the application/credential+ld+json MIME Media Type specifically for identifying documents conforming to the Verifiable Credentials format.
...
Note that while the Verifiable Credentials format uses JSON-LD conventions, there are a number of constraints and additional requirements for Verifiable Credential implementations that justify the use of a specific media type.

We should be clear if we're talking about "Credentials", "Verifiable Credentials", or "the Verifiable Credential Data Model".

@msporny
Copy link
Member Author

msporny commented Feb 20, 2023

Keep in mind that we might have an application/verifiable-credential+ld+json and application/verifiable-presentation+ld+json media type incoming (or not!), so the language might have to reflect that as well. With that in mind, how about something like this:

This specification registers the application/SOMETHING media type for identifying conformant documents (link to document conformance section of the specification) that express a (credential|verifiable credential|presentation|verifiable presentation).
...
Note that while the Verifiable Credentials Data Model uses JSON-LD conventions, there are a number of additional constraints and requirements that justify a specific media type.

@TallTed
Copy link
Member

TallTed commented Feb 20, 2023

I've said things like this elsewhere, but those seem to be closing with this to track the ongoing, so...

I'm fine with one media type being used for both Verifiable and UNverifiable Credentials, and that or another single media type being used for both Verifiable and UNverifiable Presentations.

Whether the media type(s) is(are) branded "Verifable" or not, the specified structure should allow for the presence or lack of the proof(s) necessary for that verifiability, which presence or lack is what determines whether the data contained in the structure is or is not verifiable.

@Sakurann Sakurann added editorial Purely editorial changes to the specification. ready for PR This issue is ready for a Pull Request to be created to resolve it media-type labels Mar 13, 2023
@msporny msporny self-assigned this Mar 16, 2023
@OR13
Copy link
Contributor

OR13 commented Jun 6, 2023

IIRC this has been done, and can be closed.

@brentzundel brentzundel added the pending close Close if no objection within 7 days label Jun 6, 2023
@iherman
Copy link
Member

iherman commented Jun 7, 2023

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

  • no resolutions were taken
View the transcript

1.11. Fix media type registration language (issue vc-data-model#1052)

See github issue vc-data-model#1052.

Phillip Long: close it!

Brent Zundel: This looks like it has been addressed, pending close?

all: No objections.

@brentzundel
Copy link
Member

No objections raised since marked pending close, closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
editorial Purely editorial changes to the specification. media-type pending close Close if no objection within 7 days 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

6 participants