Assert claim.subject==linkingKey, for jwt.

[G8XSU]

Refer: #26 (comment)

Since VSS uses claim.subject as the user identity, I still think the client should verify that it matches the linkingKey.

Otherwise, if the auth-server—intentionally or unintentionally—returns a different claim.subject, the client could end up reading or writing data against a different key.
Even if the data is encrypted on the client side, this could still increase the risk of unintended exposure.

[G8XSU]

@tnull @wvanlint
What do you think?

[tnull]

AFAICT it would make sense, although I'm not sure if @wvanlint had some alternative use cases in mind when he decided against this in the referenced discussion.

[wvanlint]

I think I was mainly wondering there whether that's an implementation detail - the only required invariant could be that the same authentication identity maps one-to-one to the same JWT subject.

Perhaps allowing any type of subject could be useful to support multiple authentication methods and decouple the VSS namespacing from the LNURL Auth linking key.

Otherwise, if the auth-server—intentionally or unintentionally—returns a different claim.subject, the client could end up reading or writing data against a different key.
Even if the data is encrypted on the client side, this could still increase the risk of unintended exposure.

Wouldn't assuming that the authentication server is malicious/broken have additional consequences as well?