"4. Metadata" section content
Issue #1884
closed
- Sections 4.1-4.6 are not directly related to the core purpose of OpenID Federation. and there would be federation specification implementations that would use existing oauth/oidc metadata discovery mechanisms (rfc 8414 etc.) instead of metadata parameter in the entity configuration(and this specification does not/cannot prevent that.). they should probably be moved to the Annex. section 4.7 Federation entity should probably stay in section 4.
- Is there a use-case for Section 4.6 OAuth protected resource? It relies on an expired draft. and it seems premature to optimize for a general purpose resource server. Suggest to take out this section from the document.
Comments (8)
-
-
- changed status to open
There is agreement that deployments can choose to obtain metadata from locations other than signed entity statements if doing so complies with the trust model of the deployment profile. https://bitbucket.org/openid/connect/pull-requests/448 was a first attempt at saying this in the specification. (I do understand that it would be clearer to some readers if we say this at the appropriate locations in the body of the specification, rather than an appendix and I plan to create another PR doing so, as discussed in Yokohama.)
But moving the description of how to include metadata in signed entity statements to an appendix would be equally confusing to implementers who want to do so; therefore, I don't think having that in an appendix is appropriate either. There are communities - especially research and education federations - where this is core functionality. It is important to be clear that whether to retrieve metadata from signed entity statements or other locations is a deployment choice dependent upon the trust model chosen by the deployment. I will endeavor to clarify this in my upcoming PR on this topic; this PR may restructure the text to separate 4.7 from 4.1-6, as suggested.
-
I understand what you are saying. I nevertheless believe the Federation spec should not define the metadata conveyed in the entity statements. That’s not at the core of the spec.
I’m not sure why you emphasis the “signed” entity statement. If signed metadata is important to the deployment, the place where the data is maintained and signed does not matter. Could be the entity statement, could be any well known location.
-
Is there a use-case for Section 4.6 OAuth protected resource? It relies on an expired draft. and it seems premature to optimize for a general purpose resource server. Suggest to take out this section from the document.
Yes, see https://bitbucket.org/openid/connect/issues/1844/federation-request-more-scenarios-use
-
One of the characteristics of Federation that made me decide to implement it was the possibility offered to a RP to publish its own metadata on a well-known resource.. Signed! Coming from the Research and Scholarship type Enterprise infrastructures and landing on the Government ones, this was an unavoidable requirement for me.
Objectively, it was the only way for RPs to publish metadata on a well-known endpoint, correct me if I'm wrong, at least three years ago.
However, a lot of water has passed under the bridge in the last 3 years and a renewed awareness of the unexpressed potential of OpenID Federation is giving us the opportunity to dare further. And fortunately we’re on time for this!
As long as OpenID Federation optionally allows Core and OAuth 2.0 metadata to be published within openid-federation, I don't see any issues.
I think that we can configure the metadata as OPTIONAL in the Entity Configuration. There may be some cases where a protocol doesn’t have any metadata but OpenID Federation is required in the infrastructure to attests the trust to a specific URL. I promise I'll bring a concrete use case for this, because I'm working on it, because it was explicitly requested in the design of some interop infrastructure that looks at OpenID Federation without involving OpenID or OAuth 2.0 protocols.It's ok for me the removal of "metadata" as mandatory in the Entity Configuration (see https://bitbucket.org/openid/connect/pull-requests/510/federation-introductionary-text-cleanup#Lopenid-connect-federation-1_0.xmlT428) provided that a clear approach is explained for those who implement and for those who validate the metadata.
Then, my proposal is below:
The metadata in the Entity Configuration, if present, should be considered as the sole. Then, if an OP uses both
.well-known/openid-configurationand.well-known/openid-federationand publishes its metadata in openid-federation, this latter should be considered.Regarding the risk to duplicate the metadata in both
.well-known/openid-federationand.well-known/openid-configuration, I simply say that it’s NOT RECOMMENDED but I don't feel like forcing the implementers not to do it.We don’t have also to forget that OpenID Federation extends the OP metadata claims, with “organization_name”, “signed_jwks_uri“, “client_registration_types_supported“, “federation_registration_endpoint“, “request_authentication_methods_supported“, “request_authentication_signing_alg_values_supported“. All these claims should then be available at
.well-known/openid-configurationif the OP’s metadata is not published in.well-known/openid-federation
-
-
assigned issue to
Michael Jones
-
assigned issue to
-
We discussed this on the 6-Oct-23 Federation editors' call. There are two topics in this issue. The first is largely a duplicate of https://bitbucket.org/openid/connect/issues/1658. The second is being addressed by the standardization of https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata/.
We propose to resolve this issue on that basis in a week unless a reason is identified to keep it open.
-
- changed status to closed
The week has passed and no comments where received.
- Log in to comment
I think the specification needs to clearly describe the relationship between federation management and actual protocols and APIs like OpenID Connect, OAuth or OpenID for Verifiable Credential Issuance, …..
The core functionality of OpenID Connect Federation is the management of trust chains/graphs based on statements issued by trusted 3rd parties about other entities. This is about entities, signing keys, and hierarchies/graphs.
It does not require mechanisms to provide any metadata specific to a certain application or protocol. To the contrary, OpenID Connect Federation should focus on the trust aspect and leverage existing mechanisms for application or protocol specific metadata. That means, if an application has decided (based on federation data) it can trust another (leaf) party, the metadata required for a certain protocol should be obtained the way it is specified for that protocol. In case of OpenID Connect, that would be “.well-known/openid-configuration”.
Just as an example, the entity https://op.example.com could have the following .well-known locations:
Since those configurations are maintained by the same entity (identified by its URL), if trust in this identifier (and its keys) is established, it is save to assume the data in the other files can be consumed.
Such a modular approach would help adoption, it would be truly modular and extensible, and it would reduce the size of the federation specification (e.g Section 4 could be shrinked to 4.7 only).
As a bonus feature, the trusted keys distributed through OpenID Connect Federation could be used to sign application/protocol specific metadata (if needed). That comes handy if a deployment wants to use the
trust_chainparameter. This parameter could be extended to carry not only entity statements but also signed application/protocol specific metadata. Pretty powerful!Baseline: entity statements should contain keys, policies, and whatever attributes the federation entities want to assert as part of the federation management. Anything else should be outside of the scope of OpenID Connect Federation.