You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
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.:
sub
== RP's Entity ID ("The subject of the JWT is the Entity itself.")typ
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 theaud
claim.Edit: The JWT RFC requires checking the
aud
claim (however, this still does not necessarily imply that theaud
value must be the RP's Entity ID, it just means the the RP can "identify itself" with theaud
value).authority_hints
leads to Trust AnchorHow 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
This sentence is hard to parse, splitting it into two might help, e.g.,
The text was updated successfully, but these errors were encountered: