The current implementation is tightly coupled to incoming authentication being set on the gRPC request, which introduces two challenges:
There are situations where the entity minting the token is not the entity using the justification (e.g. a proxy, pair debugging). Per the design document, services need to verify that the JWT subject matches the caller subject; it's not the JVS' job to verify a caller's identity matches the identity of the justification. If someone mints a token for an incorrect email address, downstream clients should reject the request when the calling identity doesn't match the justification identity (subject).
There are many ways one might authenticate to a JVS (API, IAP, proxy, CLI, UI), and all of these have unique ways of interacting with the service.
This PR decouples the "metadata extraction" from "subject setting" and enables callers to mint JVS tokens with any provided subject.
The current implementation is tightly coupled to incoming authentication being set on the gRPC request, which introduces two challenges:
There are situations where the entity minting the token is not the entity using the justification (e.g. a proxy, pair debugging). Per the design document, services need to verify that the JWT subject matches the caller subject; it's not the JVS' job to verify a caller's identity matches the identity of the justification. If someone mints a token for an incorrect email address, downstream clients should reject the request when the calling identity doesn't match the justification identity (subject).
There are many ways one might authenticate to a JVS (API, IAP, proxy, CLI, UI), and all of these have unique ways of interacting with the service.
This PR decouples the "metadata extraction" from "subject setting" and enables callers to mint JVS tokens with any provided subject.
TODOs