-
Notifications
You must be signed in to change notification settings - Fork 4
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
Implementers that are willing to trust TLS #4
Comments
Imported from AB/Connect bitbucket - Original Commenter: mbjWe discussed this during the 3-Apr-23 working group call, including how it relates to PR #448 and its possible replacement(s). |
Imported from AB/Connect bitbucket - Original Commenter: tlodderstedtI agree with Kristina. I just presented OpenID Federation to members of the IDunion project (government funded research project on decentralized identity in Germany). Among the first reactions was “you could also assert the endpoint instead of the jwk, right?”. OpenID Connect is so successful because it embraces the concept of “make simple things simple and complex things possible”. Federation should live up to this concept as well. What is needed, in my opinion, are two features:
This should be a supported statement: {
"iss": "https://local-authority.example.com",
"sub": "https://credential-issuer.example.com",
"iat": 1516239022,
"exp": 1516298022
} It asserts the entity |
Imported from AB/Connect bitbucket - Original Commenter: peppelinuxA trust model requires that the attestations produced in the past cannot be repudiated. For this reason the trust chain is cryptographically verifiable and the historical registry endpoint publishes the historical keys, to allow all participants to be able to prove an entity statement or a trust chain produced in the past. I am in favor of a relaxation of some aspects provided that this relaxation does not remove the requirements currently fully satisfied by oidc federation. I suggest leaving the fetch endpoint as it currently is, with the current signature and schema, and getting a proof guaranteed by TLS alone, as result from the listing endpoint, which effectively returns a plaintext json response. I propose to simply add the "sub" parameter in the listing endpoint to get the entity id of a trusted subject, in clear text. then, request would be:
if trusted: response status code 200 and the body content below
else: response status code 404 This proposal harmonizes what we already have without introducing any breaking change, and also, removes from the response the claims “iss”, “iat” and “exp”, considering that in absence of a signature these may not have any sense |
Imported from AB/Connect bitbucket - Original Commenter: peppelinuxBased on my previous comment, I would move trust mechanisms based on TLS alone to the following endpoints
A trust verifier that needs to certify trust on a participant, identified as an entity ID, obtains it from the listing endpoint after which it can fetch the OIDC metadata, as in the classic example of .well-known/openid-configuration, as exemplified below: |
Imported from AB/Connect bitbucket - Original Commenter: peppelinux |
Imported from AB/Connect bitbucket - Original Commenter: peppelinuxSee also https://openid.net/specs/openid-connect-federation-1_0.html#section-2.1 |
Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1912
Original Reporter: KristinaYasuda
The entire OpenID Connect Federation specification is written under the assumption that TLS cannot be relied. which is valid under certain use-cases, but increases barrier of implementation for those implementers who trust TLS and are trying to use multilateral trust establishment mechanisms defined in the federation specification.
For example, introduction in the OpenID Connect Federation Specification states
and there are numerous statements that entity statements are always signed objects.
to increase adoption, would suggest make it clear that one way to implement is to sign entity statements, and another is to trust TLS.
The text was updated successfully, but these errors were encountered: