trust_anchor_id in entity statement?

[Torsten Lodderstedt]

trust_anchor_id

OPTIONAL. An OP MUST use this claim to tell the RP which Trust Anchor it chose to use when responding to an explicit client registration. The value of trust_anchor_id is the Entity Identifier of a trust anchor.

It seems the trust_anchor_id should better be a registration response parameter.

Why does the OP generate a new entity statement thus becoming an authoritative source of claims/policies about/regarding an RP? Shouldn’t that be the responsibility of the RP’s trust chain only?

Why doesn’t the OP just return the data as defined in OpenID Connect Dynamic Client Registration or RFC 7591 + additional response parameters relevant for OIDC federation?

The example in section A.3.2. “disables” the refresh token grant type via policy. I think this is not a policy decision but a discovery aspect.

[Giuseppe De Marco]

The Op may participate to more than a single federation, that's why the RP choose the TA where It belongs to and the OP returns the proof to which TA it has resolved the RP

On the choice of issuing a statement in the Op Response: the Op uses the signed statement as verifiable proof. Do you suggest to adopt a custom signed artifact for this Response and not an entity statement? It has sense, however It represent a formal/cosmetic way to do the same things the entity statement does. Do we have some additional benefit adopting a custom artifact/jwt for this? Probably using the entity statements in this endpoint May disorient the readers? A custom jwt would do give the same benefits of an entity statement, Yes. This needs meditation.

The Op can return a statement with the metadata claim containing the full metadata as enriched by the Federation specs

The policy can disabile the refresh grant, because in a federation there could be several implementation constraints. The metadata policy applies, technically, to all the metadata claims, indipendently by their nature or scopes

‌

‌

‌

[Torsten Lodderstedt]

I think we should revisit the design and consider to directly use OpenID Connect Dynamic Client Registration (or RFC 7591) and just add another parameter to pass the entity configuration in the registration request. I don’t see a need for a federation specific client registration response. OpenID Connect Dynamic Client Registration allows the OP to return a client id.

[Giuseppe De Marco]

Well, considering that I’ve not implemented the explicit registration I can meanly vote in favor of this proposal. My worries are related to who has already implemented this endpoint.
Standing at how mature this draft is I’m quite worried about the breaking change this may represent to the implementers (see low blow on the dictionary).

Considering that I would give the floor to the implementers of the explicit client registration and their claims, I agree to your proposal and I’d also add the following elements:

1. we may add a more complex, wider and extendible claim to attests the trust mechanisms supported by the client/RP, eg:

"supported_trust_mechanisms”: [
  {
    "type": "openid-federation",
    "properties": {"entity_id": "https://url.of.the.rp"},
  },
]

For this reason I’d support the removal of the explicit client registration from the Federation specs and the creation of a new draft that extends Dynamic client registration with this claim, with the purpose to cover Federation, OpenID4SSI, EUDIW Trusted lists, TRAIN and whatever represent a well known way to establish the trust, dynamically. This may close several issues we have over there, in a single shot :-)

2. The response from the OP should be signed with the jwk trusted in the supported trust mechanism used by the RP to trust the OP.

could such an ambitious change justify such a radical shift in the draft?

Probably the answer will be: leave explicit registration as it is and go ahead, if you want/can, to another draft that merges all the different worlds in a single specification!

[Michael Jones]

Discussed on the 6-Oct-22 working group call. @Roland Hedberg - it would be great if you could think about this one.

[Roland Hedberg]

The specification wants to allow the OP to modify the RP’s metadata much as it can be done when doing dynamic client registration according to OIDC core. The way to do it in OIDC fed is to insert the OP’s response which may contain metadata_policy/metadata in-between the RP's entity configuration in the trust chain between the RP and the TA (chosen by the OP) before collecting policies and applying them to the metadata.

This means that whatever metadata policies are present in the federation will be applied before the OPs metadata policy. The reason for this is that the OP shouldn’t be able to change the RP’s metadata in such a way that it doesn’t follow the federations policy.

[Torsten Lodderstedt]

What changes is an OP allowed to change? I’m asking since the RP is (in my opinion) not an authoritative source of a RP entity statement.

Why isn’t it sufficient to just return the change client data using the standard registration response (which is kind of an adopted entity configuration) and let the RP apply policies?

[Roland Hedberg]

All the changes it is allowed to do according to OIDC core. With one caveat and that is that it has to be within the policy that is constructed from the trust chain.

‌

[Torsten Lodderstedt]

Which relates to the policy someone else defined, correct?

I accordance with the spirit of RFC 7591,

The client or developer can check the values in the response to
determine if the registration is sufficient for use (e.g., the
registered "token_endpoint_auth_method" is supported by the client
software) and determine a course of action appropriate for the client
software.

I think it is possible the OP just returns the metadata with a dynamic registration response (RFC 7591). The RP would need to check the compliance with the policy (in the same way it would check whether the setting make a technical sense).

I repeat my proposal to use standard dynamic client registration for federation instead of introducing a new kind of registration endpoint.

[Giuseppe De Marco]

I think that we can introduce dynamic client registration in Federation, as it is, and that this latter could be extended with the trust mechanism defined in OIDC Federation.
The choices are if we need to let Federation specs out of this aspect and create a specialized draft that extends dynamic client registration using oidc federation (solution A), or simply add a section in the current Federation draft for this (solution B). Or simply do nothing and reject this proposal (solution C).

The sole requirement, if I understand well, is that we can’t remove/change the explicit client registration model, because of the preexisting implementations we have to honour.

We have to discuss it better with the authors and …I’m wondering if a good and very small PR would open the proposal in the right way (@torsten that would be up to you if you agree).

Even if the solutions A or B would be adopted we have the problem of how the metadata would be updated if something changes, so in this solutions we need to cover also the client configuration endpoint as specified in https://openid.net/specs/openid-connect-registration-1_0.html#ClientConfigurationEndpoint.

the OP that registers the RPs should keep the trust chain that belongs to its RP registrations periodically updated, otherwise we would abandon the metadata policy feature and I don’t think that this would be possibile, becase this is one of the most important feature in Federation.

[Roland Hedberg]

@Torsten Lodderstedt I don’t think standard dynamic client registration belongs in this specification for a number of reasons.

1. The content is clear text and is not protected by a cryptographic signature
2. There is no way to enforce federation policies.
3. You can not discover if the RP belongs to the same federation as the OP.

I think you should write a separate document where you describe how using OIDC core dynamic client registration in a federation would work.

[Michael Jones]

It seems that Roland essentially made the same point above that I made at https://bitbucket.org/openid/connect/issues/1658/clarification-on-op-metadata-section-43#comment-64207318

The key issue seems to be establishing that the RP is a member of the federation.

‌

[Vladimir Dzhuvinov]

What is the value of explicit registration? Remove it or keep it?

• Before the trust_chain parameter invented by the Italian federation, explicit was invaluable in enabling clients to join a federation without the need to host an own endpoint. Besides, for some types of applications hosting a web endpoint is technically not possible.
• Even with the power of the trust_chain parameter in automatic registration, explicit registration has serious appeal to OPs with existing servers who want to implement federation, but without touching existing OIDC/OAuth code. A smart implementer will notice that the federation_registration_endpoint can be run as a separate web service, which then wraps (acts as a facade) to the dynamic client registration API (RFC 7591, 7592) of the std OP server. Alone for this reason the explicit registration must stay.
• Explicit registration holds similar appeal for RPs based on std OIDC/OAuth code. After the federation registration is completed, the OAuth flows and requests remain unchanged, i.e. “regular” OIDC.

What is the trust_anchor_id doing in registration responses (their statements)?

• In a federation with a single trust anchor / authority this parameter isn’t needed.
• But suppose we have a multi-country federation, where the OP is part of the Italian and the Bulgarian federation, which the RP both recognises.
• The two authorities however have slightly different metadata policies.
• The trust_anchor_id is there to tell the RP which authority - the Italian or the Bulgarian - was chosen by the OP, and thus let the RP know which trust chain (with policies) must be applied to verify the registration response.

Signed statement or unsigned (TLS only) registration responses?

• An unsigned response proves that it comes from the domain of the entity.

• The registration response as a signed statement is best seen as the last piece that when added to the trust chain will:

  • let the RP verify, using the existing standard trust chain validation logic, that the response is ultimately trusted (reaching the trust_anchor_id).
  • let the RP construct its effective metadata, shaped by the policies in the trust chain, again using the existing standard trust chain validation logic.

• On the surface there is this appeal to “optimise away” the statement in the registration response, and simply let the RP do its “checks”.

• An RP however, one way or another, needs to be capable of resolving and validate trust chains (as is the case with TLS/X.509 certs). That same logic is used to process the explicit registration responses. With a explicit registration response a different “kind” of trust chain is fed into the routine, and the result is the JSON object for the RP metadata.

‌

‌

[Torsten Lodderstedt]

I revisited section 10.2.1.2.2., clause 2. It seems the RP is supposed to use the entity statement returned by the OP to produce its effective statement. Can you please shed some light on why this is required? I’m asking since if the same client would run through the automatic registration process, the OP would produce the effective client policy/metadata and process the request accordingly. No metadata/policy processing on the client side. Why that difference?

[Vladimir Dzhuvinov]

A key feature of explicit registration is that it enables OPs to provision registration params, like client_id , client_secret , etc, and thus enable RPs that cannot handle public key based client auth. Automatic registration, as it is, cannot facilitate the provisioning of anything by the OP to be communicated directly back to the RP.

In the early versions of the spec the mechanism to provision such parameters in a entity statement was via the policy language. Which meant the RP must parse and process the statement policy to obtain its credentials. A recent update to the federation spec and the entity statement format makes it possible for the OP to directly pass such metadata (client_id, etc) back to the RP, a great improvement and simplification.

If the underlying question is - can the policy processing (not the metadata processing) be skipped for an explicitly registered RP - I suppose it could. But processing it can be seen as a good extra check. In auto registration, the RP has no way to find out (programmatically) when an authZ request failed because of a policy error, and also no way to know what effective policy was applied.

‌

[Torsten Lodderstedt]

If the underlying question is - can the policy processing (not the metadata processing) be skipped …

yes, even better to drop this requirement altogether. That would allow to return a plain client registration response with the data any client already using DCR would understand.

I think that would make adoption of the spec much simpler.

[Takahiko Kawasaki]

It was after I finished implementing the federation registration endpoint (i.e. “explicit” client registration) that I noticed existence of this issue (Issue 1655). (^_^;

The following is just a comment from an implementer.

My implementation accepts both application/entity-statement+jwt (entity configuration) and application/trust-chain+json (trust chain), applies metadata policy, and issues an entity statement including trust_anchor_id. The value of metadata/openid_relying_party/client_id in the payload of the entity statement is a new value assigned by the authorization server which is different from the entity ID.

Regardless of whether an input to the federation registration endpoint is an entity configuration or a trust chain, the endpoint implementation has to verify the trust chain. If there is a good library (e.g. Nimbus OAuth 2.0 SDK with OpenID Connect extensions, a great work by Connect2id and contributors), applying metadata policy is not a heavy task once a verified trust chain is available.

[Vladimir Dzhuvinov]

yes, even better to drop this requirement altogether. That would allow to return a plain client registration response with the data any client already using DCR would understand.

I think that would make adoption of the spec much simpler.

I meant allowing RPs to skip the policy check, or specifying optional return of plain DCR response. Not dropping the current structure entirely.

In federations with multiple trust anchors, not having feedback which trust_anchor_id was chosen, can potentially make it very difficult algorithmically or costly computationally to find out which policy was applied (to be able to verify it), and hence verify the DCR response for compliance (unless the RP wants to “just” trust the DCR response from the OP and take it as it is).

The current OIDC Federation model also isn’t clear, but seems to imply that the trust chain resolution will always result in a single RP metadata in the “mind” of the OP. This has the implication that auto registering RPs can unexpectedly receive errors in the OAuth flow when the federation starts having multiple trust anchors (or even intermediates): Suppose the OP ends up with an effective policy for the token_endpoint_auth_signing_alg as one_of[RS256,ES256] and chooses RS256 (assuming a single RP metadata model). The RP has no way to know (in auto registration) what alg was chosen, and in the token request for private_key_jwt auth ends up choosing the ES256. The token request then fails :)

RPs can also experience similar errors, e.g. in ID token validation, if they have the single RP metadata model (or their RP library does so) for metadata like id_token_signed_response_alg.

I have brought this issue up with the editors. What particular RP metadata model the OP has - single or variable - also affects how the explicit registration response is constructed - in the single metadata model all RP metadata will be in the metadata.openid_relying_party (essentially a DCR response), but if the variable model is chosen, the variable metadata will have to go into the “policy” and the metadata.openid_relying_party will be partial.

[Giuseppe De Marco]

the value and benefits of the current approach is to allow a single registration for multiple roles

a leaf which is at the same time RP and RS and OP and so on

the signed proof of accreditation, non-repudiable proof by the accrediting federation entity

The trust anchor ID makes explicit at which trust anchor the trust was resolved, making it clear to the leaf how the policy and constraints were applied

The current approach offers greater benefits than the classic DCR procedure

[Vladimir Dzhuvinov]

The trust anchor ID makes explicit at which trust anchor the trust was resolved, making it clear to the leaf how the policy and constraints were applied

The trust_anchor_id is not sufficient, the authority_hints is also necessary for the RP be able to figure out what policies and constraints to apply to the returned metadata for its registration.

[Roland Hedberg]

Well, yes if there are more than one way between the leaf and the trust anchor.

While possible, I’m not sure how likely it is. If you are concerned about this then you have to list all the authorities used between the leaf and the TA.

[Giuseppe De Marco]

Listing all the intermediaries would be more like a verifiable trust chain, that gives the path from the leaf to the TA, so authority_hints, alone is not so efficient or less efficient thant the entire trust chain

[Vladimir Dzhuvinov]

This a list of the entity statement claims used in explicit registration, according to draft 29:

EC in explicit registration request:

Always required:

• iss
• sub
• iat
• exp
• jwks

Required for requests with EC in explicit:

• aud -- set to the entity ID of the OP
• authority_hints
• metadata

Optional

• trust_marks

Ignored / forbidden: all others

ES in explicit registration response:

Always required:

• iss
• sub
• iat
• exp
• jwks

Required for response with ES in explicit:

• aud -- set to the entity ID of the RP
• authority_hints -- must be single valued
• trust_anchor_id -- set the chosen TA
• metadata -- RP metadata provisioned by the OP

Optional

• metadata_policy -- when the OP must shape / modify the RP metadata, see iss #1794

Ignored / forbidden: all others

[Michael Jones]

On the 12-Jun-23 working group, we discussed that Explicit Client Registration should have a more structured description of the parameters.

[Vladimir Dzhuvinov]

Substantial PR reworking explicit registration here:

https://bitbucket.org/openid/connect/pull-requests/609/federation-reworks-explicit-registration

[Michael Jones]

Addressed by https://bitbucket.org/openid/connect/pull-requests/609