-
Notifications
You must be signed in to change notification settings - Fork 134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Designing list of requirements for new IDPs for public good deployment #397
Comments
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? |
Out of curiousity:
What's the requirement for this? Also, I'm wondering about:
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:
|
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. |
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 |
I.e. New IDP Requirements: https://github.com/pwelch/fulcio/blob/main/docs/new-idp-requirements.md Thanks! |
This was merged in - https://github.com/sigstore/fulcio/blob/main/docs/new-idp-requirements.md |
Description
In today's community meeting, we discussed two ways of supporting new IDPs:
We need to determine what are the requirements for a new IDP before inclusion.
Some initial thoughts:
.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)iss
,sub
,aud
, for some examples), but that these values are represented in some claim on the token. For example, the subject could be insub
oremail
or maybe some other claim.aud
) for the token, setting the audience tosigstore
What else would we like to see in in IDPs?
The text was updated successfully, but these errors were encountered: