Remove duplicate descriptive language

[selfissued]

This removes duplicate language in the description of the use of JOSE header parameters and JWT claims. In the process, I moved the "JOSE Header Parameters" section before the "Key Discovery" section.

I added missing COSE content that corresponds to existing JOSE content.

I moved the "Wallets" section nearer to the end.

I believe that this is the last thing that we must do before submitting for CR.

Fixes #135

---

Preview | Diff

[TallTed]

As noted many other places, just as there is no such thing as application/jpg+zip, the application/vp+ld+json+sd-jwt media type should not exist; this media type should be simply application/sd-jwt. The described reasoning behind wanting media types like application/vp+ld+json+sd-jwt would be well satisfied and better conform to RFC history by specifying profiles for the application/sd-jwt media type.

[selfissued]

@TallTed wrote:

the application/vp+ld+json+sd-jwt media type should not exist; this media type should be simply application/sd-jwt.

This PR does not change the media types in the specification, nor is it the right place to do so. Therefore, @TallTed, I'd ask you to withdraw your suggestions to change the media types here, since that's not the topic of the PR. If you want to discuss media types, I believe that issue #179 is already the right place to do so. Thanks.

[decentralgabe]

I'm not sure about this. Does this prevent DIDs that do not use publicKeyJwK from creating vc-jose-cose objects?

[selfissued]

I'd turn the statement around. It makes it clear that DIDs used with vc-jose-cose need to support the JWK key representation. This increases interoperability.

[OR13]

I prefer the SHOULD, since I don't plan to be working with JSON in the future, whenever possible.

[decentralgabe]

generally looks great - few small comments

[OR13]

For the sake of consistency this will also need to update, depending on #184

[OR13]

Overall, these changes seem excellent.

I don't think there is any normative changes here, except for the SHOULD to MUST regarding key representations...

I note that this would prevent future implementers from using a COSE Key to verify a SD-JWT.. perhaps that is acceptable.

[OR13]

@TallTed I filed, #184

to track your request to adjust the registration requests associated with typ.

lets get the argument for why you think that change should be made clearly captured there, and we will need to address it pre CR, I am going to resolve those suggestions for now.

[OR13]

@TallTed I sent some emails to the relevant lists regarding your proposal, lets continue the media type parameter discussion on #184.

Can you review again (assuming we will address 184 separately before CR) ?

Edit: I changed my mind, I think we need to address @TallTed 's comments in this PR, or at least have a path forward regarding profile and application/vc+... see w3c/vc-data-model#1363

[OR13]

I'd like to get clarity on the profile issue related to the core data model, before we merge this... see:

w3c/vc-data-model#1363 (comment)

[OR13]

After editors call, I agreed to address @TallTed 's feedback on typ in a separate PR, which is now up here: #186

There will be merge conflicts, if this PR is merged, but I can address them, and #186 makes it clear one way to resolve this issue.

[OR13]

Open for a week, no objections, merging.