Implementers that are willing to trust TLS

[OIDF-automation]

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

OpenID Connect Federation Trust Chains rely on cryptographically signed JSON Web Token (JWT) [RFC7519] documents, and the Trust Chain does not at all rely on TLS [RFC8446] to establish trust.

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.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: mbj

We discussed this during the 3-Apr-23 working group call, including how it relates to PR #448 and its possible replacement(s).

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt

I 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:

1. allow retrieval of JSON entity statements from trusted endpoints
2. assert entity identifiers in entity statements

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 https://credential-issuer.example.com is trusted by https://local-authority.example.com.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: peppelinux

A 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:

https://local-authority.example.com/list?sub=https://ntnu.andreas.labs.uninett.no/

if trusted: response status code 200 and the body content below

200 OK
Content-Type: application/json

[
  "https://ntnu.andreas.labs.uninett.no/"
]

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

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: peppelinux

Based on my previous comment, I would move trust mechanisms based on TLS alone to the following endpoints

• .well-known/openid-federation (if requested in plain text)
• listing, it returns the list of direct subordinates by entity IDs, in plain JSON
• trust mark status endpoint, it returns the status of a compliance of a subject, in plain JSON

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:

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: peppelinux

See also https://bitbucket.org/openid/connect/issues/1802/heather-flanagans-comment-on-the-use-of#comment-65338224

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: peppelinux

See also https://openid.net/specs/openid-connect-federation-1_0.html#section-2.1