Skip to content

Designing list of requirements for new IDPs for public good deployment #397

@Hayden-IO

Description

@Hayden-IO

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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions