Handling of relative kid for v1.0 of the profile

[troyronda]

Part of #44

[Sakurann]

I think we need to wait for a resolution on https://github.com/w3c/vc-data-model/issues/914 before we merge this PR

[tplooker]

I disagree, option 1 is a security issue and inconsistent with other usages of JWT, we should only be using option 2.

[Sakurann]

Could we please add more text on safer way for absolute url processing. and to add text wrt security context behind the text

[tplooker]

The security issue with allowing absolute url's in the kid field is that an implementation can easily forget to check the did portion of the kid field to the iss value by just verifying the JWT based on the kid field. Failing to do that leads to the verifier to believe the JWT was signed by an issuer it was not. By using a relative URL in the kid field, the verifier has to use both the iss and kid values to resolve the public key required to validate the JWT therefore removing the possibility of the scenario described above.

[jischr]

@troyronda can you separate this out for the v0.1 release that we discussed last week?

[troyronda]

@jischr @Sakurann @tplooker I created a note describing the current situation.

77

Summary:

• Noted that implementors currently use an absolute kid URI in VCs.
• Guidance on absolute and relative URIs.
• Noted the current debate and the potential for requirement changes from the spec/profile.
• Due to the potential for transition, implementors may want to consider accepting both.