Define hybrid model of subject-signed and attester-signed ID tokens

From PR #48, specifically this comment, on adding an id_token_type request parameter to request subject-signed or attester signed ID Tokens.

If we define a request parameter to switch the security model of the OP on a request-by-request basis, we need to change the SIOP processing model to include this hybrid processing model for traditional third-parties.

There are several extensions as part of SIOPv2 which are not packaged as being general purpose for transactions with a more traditional OP or for OAuth. Some of these are explicitly called out as being inappropriate, such as the registration parameter, are explicitly recommended against currently for security reasons.

If an OP is operating in both a SIOP and traditional OP model, we need to document how that can be done securely with request and response processing steps.

If an RP can request one mode or the other on a request-by-request basis, we should probably also define a use case for such behavior. For example, subject-signed and attester-signed ID tokens cannot represent the same subject and are thus not interchangeable.

Comments (1)