Skip to content
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

Validation of Explicit Client Registration Response #84

Open
SECtim opened this issue Sep 10, 2024 · 0 comments
Open

Validation of Explicit Client Registration Response #84

SECtim opened this issue Sep 10, 2024 · 0 comments
Assignees

Comments

@SECtim
Copy link
Collaborator

SECtim commented Sep 10, 2024

Section 12.2.2.2 describes how an RP validates an OP's response to an explicit client registration request.

Some of the steps are somewhat unclear to me/could be made clearer.

Valid Entity Statement

If the response indicates success, the RP MUST verify that its content is a valid Entity Statement and issued by the OP.

What exactly does "verify that its content is a valid Entity Statement" entail (apart from the issuer check that is mandatory anyway due to "and issued by the OP")?
I suppose the idea is that RP has to check what Section 3 describes, i.e.:

  • Validate the signature ("Entity Statement is signed using one of the private keys of the issuer")
  • Validate sub == RP's Entity ID ("The subject of the JWT is the Entity itself.")
  • Validate typ
  • Validate presence of the required claims, i.e., iss, sub, iat, exp, jwks

However, this could be made more explicit.
Furthermore, my understanding of the current text in Section 12.2.2.2 does not mandate the RP to check the aud claim.
Edit: The JWT RFC requires checking the aud claim (however, this still does not necessarily imply that the aud value must be the RP's Entity ID, it just means the the RP can "identify itself" with the aud value).

authority_hints leads to Trust Anchor

The RP MUST verify that at least one of the authority_hints it specified in the Explicit Registration request leads to the Trust Anchor that the OP set in the trust_anchor_id claim.

How exactly does the RP verify this? Is it sufficient to just fetch Entity Configurations? - Probably not. I suppose the intention is for the RP to do a full Trust Chain resolution & validation (which it may of course have already done before sending the registration request, in which case RP may use that cached chain if it has not expired).

This could be clarified by adding "by resolving and validating a corresponding Trust Chain."

Trust Chain-compliant Metadata

The RP MUST ensure that the metadata it was registered with at the OP complies with the Trust Chain openid_relying_party policies, which Trust Chain is resolved using the trust_anchor_id and authority_hints claims of the received registration Entity Statement.

This sentence is hard to parse, splitting it into two might help, e.g.,

The RP MUST ensure that the metadata it was registered with at the OP complies with the Trust Chain openid_relying_party policies. That Trust Chain MUST be resolved using the trust_anchor_id and authority_hints claims of the received registration Entity Statement.

@selfissued selfissued self-assigned this Sep 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants