The relationship between OPs and PK Tokens

I wanted to write up an issue on this because while we in OpenPubkey have discussed the nature of the relationship between OP (OpenID Providers) and PK Tokens there isn't much written down.

PK Token Issuance/Validity and OpenID Providers/OIDC Clients

One can not meaningfully ask if a PK Token is valid by itself. The question validity must always been understood in reference to both a OpenID Provider and an OIDC Client.

Some examples:

• With the Google OP, the PK Token is only valid if the OIDC Client ID specified in the aud (audience) claim in the ID Token matches the expected value. Additionally within the context of the Google OP we must check that the CIC is committed to in the nonce claim in the ID Token.
• Contrast this with the Github OP where there is no set aud (audience) claim to match against in the ID Token as the CIC is committed to in the nonce, but Github PK Token must be GQ signatures.
• The proposed Gitlab OP implementation has a set prefix in the aud claim which must match the expected value. Unlike GoogleOP or the Github OP, the CIC isn't committed to directly in the ID Token at all but committed to by the GQ Signature itself. https://github.com/openpubkey/openpubkey/issues/100

For things like zkLogin we can use the architectural existence of providers clients (OPs) provides an excellent point to transform SNARK based ID Tokens into PK Tokens. The makes expiration of the PK Token depend on the provider client implementation. https://github.com/openpubkey/openpubkey/issues/101

PK Token usage and OpenID Providers/OIDC Clients

Beyond just validity, using a PK Token depends on the OP.

• GoogleOP always has an email claim.
• AzureOP (currently not added) does not have an email claim (although it sometimes does). Instead the email can be looked up from Microsoft using the sub claim.
• GithubOP doesn't always have an email claim.
• zkLoginOP may or may not have an email claim but to read the email, the user must reveal a value opening the email commitment.

The following pattern fits this relationship well:

googlePkt, err := GoogleOP.Verify(pkt)
if googlePkt.email == "alice@gmail.com" {
...
}

Since we know that Google PK Tokens always have email addresses, if we cast PK Tokens to the subtypes of PK Tokens based on the OP we can let have compile time type checking of PK Token claims.