Designing list of requirements for new IDPs for public good deployment

[haydentherapper]

Description

In today's community meeting, we discussed two ways of supporting new IDPs:

• Integrating with Dex
• Adding the IDP directly to Fulcio's OIDC issuer config list

We need to determine what are the requirements for a new IDP before inclusion.

Some initial thoughts:

• As pointed out in the meeting, Dex allows us to restrict the lifetime of issued tokens. Lifetime isn't included in the hosted openid-configuration, so this may have to just be an audit and not enforced (beyond rejecting tokens that are over a certain lifetime, but at that point, the token's already been sent over the wire so it's not worth rejecting the requesting in my opinion).
• Also brought up in the meeting, we should require that IDPs prevent identity subject reuse.
• Key rotation policy
• Signing key storage policy
• Uptime requirements
• A hosted .well-known/openid-configuration (which should be a given for OIDC, but it's worth having this explicitly checked as part of onboarding a new IDP)
• Minimum set of supported claims (issuer, subject, audience, issued at, expiration). I propose that we don't enforce that all tokens have precise claim name (iss, sub, aud, for some examples), but that these values are represented in some claim on the token. For example, the subject could be in sub or email or maybe some other claim.
• An OIDC provider must challenge the email address
• A configurable audience (aud) for the token, setting the audience to sigstore

What else would we like to see in in IDPs?

[trevrosen]

On a related note, I'm curious how the Sigstore team is planning to expand the list of the cert's SAN OIDs.

I'm interested in use cases involving multiple integrated build systems which also function as an IdP (like GitHub Actions does). Will the OID list expand to cover other systems directly or are there plans to abstract build-related claims?

[evankanderson]

Out of curiousity:

An OIDC provider must challenge the email address

What's the requirement for this?

Also, I'm wondering about:

Minimum set of supported claims (issuer, subject, audience, issued at, expiration). I propose that we don't enforce that all tokens have precise claim name (iss, sub, aud, for some examples), but that these values are represented in some claim on the token. For example, the subject could be in sub or email or maybe some other claim.

I'm assuming that for a given IDP, there is a specific claim which can be used as a long-term durable identity which will not be reused (per "we should require that IDPs prevent identity subject reuse"). So a config might look like:

GitHub:
  identity_claim: sub
Google:
  identity_claim: email  # hypothetical, probably not really
Microsoft:
  identity_claim: iss + email  # Do we need to support hybrid keys?
SPIFFE:
  identity_claim: iss + sub  # Might be a good example of why to support hybrid keys

[haydentherapper]

What's the requirement for this?

Proving ownership of an underlying identity, though I don't think it's a hard requirement. We can never know for certain that hayden@gmail provided by Google is the same as hayden@gmail provided by GitHub, but having this requirement would help.

[haydentherapper]

Fixed as of #1447. Please file any issues or propose changes if you have any concerns with the proposed policy.

FYI TSC, since there was interest in this list - @lukehinds @trevrosen @priyawadhwa @bobcallaway @SantiagoTorres