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
In the spec, the example id_token has been signed with a header.kid that's different from the payload's sub_jwk kid. In general, when/why should these differ, and what processing steps should a client follow to ensure they are "consistent"?
The text was updated successfully, but these errors were encountered:
They should both be the same. That is one issue we had with the SIOP spec that we needed to introduce these kind of redundancies. Note, DID SIOP backward compatibility with the SIOP spec was a goal. That is the reason why this language is in the spec.
Ideally, in SIOP v2, we don't need to use sub_jwk if the spec allows for key indirections based on a DID.
To verify an id_token, the following must be done:
Verifying that the id_token was signed by the key specified in the sub_jwk claim.
Resolve the DID Document from the SIOP's DID specified in the did claim.
Determine the verification method from the SIOP's DID Document that matches the kid of the sub_jwk claim in the id_token.
Verify the id_token according to the verification method above. This step depends on the verification method in the authentication section in the DID Document and is out-of-scope of this specification.
In the spec, the example id_token has been signed with a header.kid that's different from the payload's sub_jwk kid. In general, when/why should these differ, and what processing steps should a client follow to ensure they are "consistent"?
The text was updated successfully, but these errors were encountered: