How to request SIOP?

[Torsten Lodderstedt]

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).

[Vladimir Dzhuvinov]

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?

[Torsten Lodderstedt]

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.

[Kristina Yasuda]

(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:

1. 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

2. 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.

3. 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

‌

[Torsten Lodderstedt]

What is the difference between personal and 3P SIOP from a conceptual standpoint?

[Kristina Yasuda]

good question. there should not be any difference if we “re-define“ SIOP correctly, based on the ability to issue self-signed ID tokens.

[Michael Jones]

I believe that https://bitbucket.org/openid/connect/pull-requests/144 is accomplishing the “re-defining SIOP correctly”.

[Torsten Lodderstedt]

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.

[Torsten Lodderstedt]

created PR #148

[Kristina Yasuda]

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.

1. 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

2. OP supports only third-party-issued ID Token

   • no changes to the OP or RP

3. OP can be both SIOP and third party OP

   • OP adds id_token_types_defaul parameter to the metadata (optionally also id_token_types_supported).
   • RP better use `id_token_type` Authorization Request parameter to avoid receiving unexpected ID Token types.

‌

[Kristina Yasuda]

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.

[Michael Jones]

What do you mean by “an overload”, Kristina?

[Michael Jones]

an overload → an overhead

[Kristina Yasuda]

PR #148

Conversation continues in Issue #1478