adds support for W3C ES256K

[scrummitch]

Adds support for decoding JWTs using EcdsaSecp256k1Signature2019 which will become very popular due to Decentralised Identifiers becoming a W3C recommendation.

These signatures are used in Verifiable Credential issuance and presentations, see here https://identity.foundation/jwt-vc-presentation-profile.

Microsoft is using this method to sign their JWTs, see here https://learn.microsoft.com/en-us/azure/active-directory/verifiable-credentials/verifiable-credentials-standards#supported-algorithms

Please let me know if I've missed anything.

[OR13]

I recommend changing "EcdsaSecp256k1VerificationKey2019" to ES256K. In the context of JWT, only ES256K is needed to signal the alg and key type.

[bshaffer]

This looks great!

One question I have is where you got the value for the EC curve (1.3.132.0.10). I searched for it online, and only found it referenced in a few websites like oid-info.com and oidref.com. It would be nice to see this value referenced from somewhere like IETF or other standards organization.

[scrummitch]

This looks great!

One question I have is where you got the value for the EC curve (1.3.132.0.10). I searched for it online, and only found it referenced in a few websites like oid-info.com and oidref.com. It would be nice to see this value referenced from somewhere like IETF or other standards organization.

@bshaffer I used oid-info.com but its also in the source code for phpseclib here https://github.com/phpseclib/phpseclib/blob/master/phpseclib/Crypt/EC/Formats/Keys/Common.php#L120

[scrummitch]

@bshaffer Would like to get your opinion on swapping the order of the merge in JWT::encode(). For example to so typ can be blanked out. RFC 7519 says its not required https://www.rfc-editor.org/rfc/rfc7519#section-5.1

from

if (isset($head) && \is_array($head)) {
    $header = \array_merge($head, $header);
}

to

if (isset($head) && \is_array($head)) {
    $header = array_filter(\array_merge($header, $head));
}

[bshaffer]

@bshaffer Would like to get your opinion on swapping the order of the merge in JWT::encode().

My initial thought is that this could change existing behavior, so unless it's a bug, I don't think we should allow it. Also, it's unrelated (AFAIK) to this PR, and so should be in a separate PR as a feat or fix.

What is the rational for blanking out typ?

[scrummitch]

@bshaffer Would like to get your opinion on swapping the order of the merge in JWT::encode().

My initial thought is that this could change existing behavior, so unless it's a bug, I don't think we should allow it. Also, it's unrelated (AFAIK) to this PR, and so should be in a separate PR as a feat or fix.

What is the rational for blanking out typ?

Agreed it should be a separate PR so i'll raise that later when required

In the DIF .well-known DID configuration file the JWT used for proof requires typ to not exist in the header so i've been working backwards from that. https://identity.foundation/.well-known/resources/did-configuration/#json-web-token-proof-format

Maybe @OR13 knows why this is a requirement ?

[OR13]

That requirement regarding typ is getting removed, I'd ignore it.

[bshaffer]

Looking pretty good! Just one more suggestion and this is good to go.

EDIT: Also, it looks like you still need to sign the Google CLA

[scrummitch]

@bshaffer thanks for the comment, ive updated that strict flag as per your suggestion.

You can see i've already accepted the CLA here: