You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be useful for applications to be able to see the OIDC issuer that was used to get the OIDC token (because in the interactive case the user selects the identity/issuer outside the application): in the sigstore case the "issuer" we are interested in is the "ultimate" issuer that is federated via the sigstore dex instance. This is useful since
application may know which identity/issuer will be acceptable in this situation and will be able to cancel before user accidentally signs with incorrect identity
Showing the identity/issuer in the UI may be useful to allow user to verify they are doing the right thing
This federated issuer does not seem to be available in IdentityToken currently. Exposing it is slightly more complicate than the identity itself... based on the python implementation it's in unverified_claims["federated_claims"]["connector_id"]
There's a related issue with IdentityToken: it always uses "email" as the identity of the token -- but some oidc issuers, like GitHub Actions, use "sub" as the identity and Fulcio does respect that...
This leads me to think sigstore-rs does not currently work in GitHub Actions? Have I missed something?
This leads me to think sigstore-rs does not currently work in GitHub Actions? Have I missed something?
Yes, we should be using sub for the identity request. The current IdentityToken's email field is an inelegant bodge that I thought I had replaced with a method dispatching to the correct identity claim. Unfortunately I never tested with a GHA token and forgot all about it. Plumbing sub through should be a pretty quick change :)
Description
It would be useful for applications to be able to see the OIDC issuer that was used to get the OIDC token (because in the interactive case the user selects the identity/issuer outside the application): in the sigstore case the "issuer" we are interested in is the "ultimate" issuer that is federated via the sigstore dex instance. This is useful since
This federated issuer does not seem to be available in
IdentityToken
currently. Exposing it is slightly more complicate than the identity itself... based on the python implementation it's inunverified_claims["federated_claims"]["connector_id"]
https://github.com/sigstore/sigstore-python/blob/main/sigstore/oidc.py#L135
The text was updated successfully, but these errors were encountered: