How to request SIOP?
There is currently no way for a RP to explicitly request self-issued ID tokens, the RP also cannot request that 3rd party attested (aka traditional) ID tokens are issued. That basically means a RP must be able to process whatever kind of ID token is returned.
I think it would be better to let the RP specify (1) what it supports (client metadata) or (2) explicitly request a certain style of ID token in the request.
(1) the client metadata parameter subject_type
is not completely suited since it only supports a single value. I would prefer a multi-value parameter.
(2) That could be done by adding another request parameter (or another multi value attribute “type” for the sub
claim in the claims parameter).
Comments (14)
-
-
reporter I’m not quite sure what the idea is .
While working on PR #120 I realized there is no way to communicate expectations/capabilities re regular vs self-issued ID tokens. As SIOP and regular OIDC are becoming more similar with every increment of SIOP v2, so I think it is good idea to at least make sure the OP understand what the RP is able to process. Otherwise a RP will face ID tokens it cannot process. That could be solved with metadata.
We need to discuss whether whether it is necessary to request a certain kind of ID token in a particular request. In that case, we need to figure out to do this in an OIDC request. -
- changed status to open
-
(I think we need to come up with a term to differentiate “traditional/third party OP using key per user and adding support to SIOP“ and “traditional SIOP where SIOP is in the user's control“ - I’m just going to use ‘3P SIOP (third party)' and 'personal SIOP’ for now)
I think there are three scenarios:
-
RP supports only personal SIOP
- the request will be tailored to it (custom schema, etc.) so that 3P SIOP will not open in the first place
- → no need to specify RP wants SIOP ID Token in the request
-
RP supports only traditional OP
- the request might be intended for traditional OP, but 3P SIOP would very likely to be able to handle it - RP will be surprised to receive Self-issued ID Token
- → if RP knows OP can be both traditional OP and 3P SIOP from OP’s metadata, it would be beneficial for the RP to clarify that it does not want self-issued ID Token,
- but than arguably, OP should determine from RP’s metadata if RP supports Self-issued ID Tokens or not and if RP does not OP should not return self-issued ID Tokens.
-
RP supports “traditional OP” and 3P SIOP
- is it OP or RP who decides whether usual or self-issued ID token is returned?
- → RP specifying preference for the type of the ID Token in the request sounds beneficial
-
-
reporter What is the difference between personal and 3P SIOP from a conceptual standpoint?
-
good question. there should not be any difference if we “re-define“ SIOP correctly, based on the ability to issue self-signed ID tokens.
-
I believe that https://bitbucket.org/openid/connect/pull-requests/144 is accomplishing the “re-defining SIOP correctly”.
-
reporter It does so we now know we only need to define a single mechanism to let the RP determine it wants a self-issued ID token.
I suggest to introduce a new request parameter “openid_selfissued” of type boolean. Alternatively if we need more flexibility, a new parameter “id_token_type” with the values “3rd-party-issued“ and “self-issued” could be used. The parameter could be omitted in case of a custom scheme based invocation.
-
reporter created PR #148
-
I support the approach in PR #148, where ultimately it’s up to the OP/SIOP to decide the type of the ID Token as opposed to the RP. Just for myself documenting the above scenarios changes as follows with the approach in the PR.
-
OP supports only self-issued (OP is SIOP)
- SIOP sets
id_token_types_defaul
to self-issued - RP will identify self-issued ID Token by iss==sub
- SIOP sets
-
OP supports only third-party-issued ID Token
- no changes to the OP or RP
-
OP can be both SIOP and third party OP
- OP adds
id_token_types_defaul
parameter to the metadata (optionally alsoid_token_types_supported
). - RP better use
`id_token_type`
Authorization Request parameter to avoid receiving unexpected ID Token types.
- OP adds
-
-
I put in the PR comment, but my only small concern is wallets/SIOPs that only support self-issued tokens might see
id_token_types_default
as an overhead. -
What do you mean by “an overload”, Kristina?
-
an overload → an overhead
-
- changed status to resolved
- Log in to comment
The
subject_type
RP reg parameter steers the encoding of the subject identifier in the ID token (and UserInfo responses).If I understood correctly, the idea is to enable an RP without changing its registration or switching between registrations / client_ids to choose between regular and self-issued ID tokens?