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

Adds a "Securing Mechanisms" section to the directory #30

Merged
merged 4 commits into from
Dec 10, 2023

Conversation

msporny
Copy link
Member

@msporny msporny commented Nov 26, 2023

This PR adds a "Securing Mechanism" section to the specification in order to be inclusive of all securing mechanism types that can be used with VCs. It then re-directs the Proof section to the "Securing Mechanisms" section (we could also just remove the "Proof" section). It places the vc-jose-cose spec into the "Securing Mechanisms" section.

This is in preparation for a set of changes we might have to make based on @jyasskin's feedback here: https://github.com/w3c/vc-data-model/pull/1338/files/20aed8c6bb9fa9f9498b90ab4c2095a6c70eab82#r1399713614


Preview | Diff


<table class="simple">
<thead>
<th>Specification</th><th>Description</th>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like it would be useful for this table to list the media types, proof.types and proof.cryptosuites that each securing mechanism handles. Otherwise, if you get a VC you don't understand, you have to read all of the specifications to figure out where it's defined.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The vc-jose-cose securing mechanism doesn't use proof at all, so at least, I wouldn't phrase it this way.

When using JOSE, the algorithms registered at https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms apply. When using COSE, the algorithms registered at https://www.iana.org/assignments/cose/cose.xhtml#algorithms apply.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Related to the question of "what version" and "what securing mechanism"... this issue on media types: w3c/vc-data-model#1363 (comment)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For JOSE/COSE, the type and cryptosuite columns would be "N/A". I'd probably use two separate tables (media type and then JSON-LD proof types) if I were dictator, to avoid needing those "N/A" values, but if the WG wants to use a single table, you can make it work.

Re the "profile" field of the media type, https://mimesniff.spec.whatwg.org/#mime-type-miscellaneous has the notion of the "essence" of the mime type--just the group/type pair without parameters--which seems appropriate to use here. I don't remember the IETF version of that notion.

Copy link
Contributor

@OR13 OR13 Nov 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is https://datatracker.ietf.org/doc/html/rfc7252#section-12.3

media type parameters can come from the top level or the subtype....text with charset for example.

Since W3C is living under application/ as a top level, and between +json as a structured suffix, the media type parameter considerations we have for our requested registration are impacted by every possible factor that you can have in a media type... top level, sub type 1, sub type n, and structured suffixes.

@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

1.1. Adds a "Securing Mechanisms" section to the directory (pr vc-specs-dir#30)

See github pull request vc-specs-dir#30.

Manu Sporny: This pull request to vc-specs-dir isn't controversial; we're going to call them 'securing mechanisms' rather than 'proofs'. This is to address some of jyasskin's concerns.
… We'll probably merge it after this call.

@msporny
Copy link
Member Author

msporny commented Dec 10, 2023

Substantive, multiple reviews, no changes requested, no objections, merging.

@msporny msporny merged commit 28e0fed into main Dec 10, 2023
1 check passed
@msporny msporny deleted the msporny-securing branch December 10, 2023 20:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants