Create guide for identity provider deployment

[haydentherapper]

This guide outlines a minimally viable identity provider to provide non-interactive signing for clients or services. This guide could be followed by a package registry for example to create a basic identity provider that doesn't fully implement the OIDC protocol but issued OIDC-compliant tokens.

Summary

Release Note

Documentation

[haydentherapper]

Wrote this up a bit ago to help onboard a new provider who didn't want to have an interactive signing flow where a user was present. This doc outlines the requirements of an identity provider that can issue ID tokens for those who are willing to stand up their own provider. This is effectively a generalization of GitHub Actions or other CI identity providers, where the identity provider a) will provide an OIDC-compliant ID token (which can be obtained by exchanging a user credential, the service generates it on behalf of a user, etc), b) the OIDC-compliant well-known endpoint, and c) the public keys endpoint provided by the configuration at the well-known endpoint.

I might merge this with the other IDP requirements doc later on, as well as an upcoming doc around public-good policy for IDPs.

PTAL and let me know if you have any feedback!

[cpanato]

looks great to me, i think it is a really nice start and eventually we can improve it

[dickhardt]

Do we want to continue to use email as a user identifier?

[woodruffw]

Do we want to continue to use email as a user identifier?

What's the alternative, for email-based IdPs? Sigstore has support for non-email identifiers as well, but email seems appropriate when the IdP is itself an email provider 🙂

Edit: oh, I see what you mean -- yeah, IMO we should distinguish between emails as identities and service users as identities: both are fine, but a service that provides usernames should represent them with OtherName rather than shoehorning them into an RFC 822 format for an inbox that doesn't actually exist.

[woodruffw]

This is great! Left one thought on identity formats/types 🙂

[woodruffw]

Per #1741 (comment): could/should we distinguish between email and non-email identities better here?

Off the top of my head, the current specified behavior is:

• A service can provide an email identity (including a 3p email identity) when that email is effectively the user identity on the service. For example, the GitHub user IDP offers [email protected] as a valid email address corresponding to the GitHub account being identified.
• If a service offers non-email user identities, it should use the dedicated OtherName form for that service, to avoid confusion/conflation with the email namespace. For example, for a new widgets.example IdP, user foo should be given the foo!widgets.example identifier.

[dickhardt]

Do we want to continue to use email as a user identifier?

What's the alternative, for email-based IdPs? Sigstore has support for non-email identifiers as well, but email seems appropriate when the IdP is itself an email provider 🙂

Edit: oh, I see what you mean -- yeah, IMO we should distinguish between emails as identities and service users as identities: both are fine, but a service that provides usernames should represent them with OtherName rather than shoehorning them into an RFC 822 format for an inbox that doesn't actually exist.

There are only 2 public providers (that I know of) that also email providers. Google and Apple. Neither works directly with Sigstore.

Using iss and sub tuple is the best practice in the identity community to identify the user.

iss is already 1.3.6.1.4.1.57264.1.8 in the certificate. A new OSI value to represent the sub in the OIDC ID Token would accurately link the ID Token and the cert

[lukehinds]

Looks good, but I would add some notes how this is for the PGS, as it being in docs, some might expect this to be guidance for private sigstore deployments (I guess it could be). I did not figure out if was the former until I reached the end (and it spoke of deploying to staging).