Registration in SIOP

Issue #1198 resolved
Kristina Yasuda created an issue

Addressing requirement D. on requirements list ”trust model between RP and SIOP”, where one of the issues is how does RP registers with SIOP and how does OP advertises its SIOP-enabled OP

The current most realistic solution seems to be - RP advertising 1/ whether it supports SIOP or not and 2/ which identifier type it supports (jwt thumbprint or a concrete did method). Because dynamic client registration/discovery is not possible.

There are foreseeable cases when RP would not be comfortable asking for concrete claims/VCs within the first interaction with OP, when RP is not yet sure if OP is SIOP or not.

Would it make sense to have to interactions between RP and SIOP with 1/ first interaction replacing ‘registration’ where RP advertises what it supports and SIOP responds if it also supports the same properties; and 2/second interaction with req-res with concrete scopes/claims?

Issue on which wallet gets invoked when the RP sends the request is in a separate Bitbucket issue.

Comments (17)

  1. Tom Jones

    This is a privacy problem - the user should be in control - so the RP could request something and the let the user or the user agent decide how to respond

  2. Tom Jones

    I learned later that this only works with polyfill. I don’t think i works for most use cases.

    @Tim this could be on special call as well - could this be a place where we ask w3c for a better interface?

    The essential issue is how does the browser react to an authn request from the RP. And what could the browser expose to the RP?

  3. Kristina Yasuda reporter

    CHAPI (Credential Handler API), which is one concrete implementation might be a polyfil, but RP providing registration information to the OP (SIOP) with user consent and without exchanging PII can be designed without polyfil, I believe.

  4. Tom Jones

    That works with the existing OIDC section 7. Two issues:

    1. the openid:// can be taken over by the latest app to be installed. The user has to accept the app, but is unlikely to know why siop quit working.
    2. The session gets “stuck” in the siop, or the siop sends to the user to a new browser session (“tab”) which breaks the user workflow.

    As i said in another thread. The issue is that there is no way with the current browsers for the user experience with SIOP to match that available from the current front-channel OIDC flow.

  5. Tom Jones

    below is what’s in section 7.3 now - what needs to change?

    As i understand the problem the claims should state what the client wants. We may want to expand the scope of these two claims.

    acr Authentication Context Class Reference

    amr Authentication Methods References

    I also want to see proofing request - so we could add something like that - also could like DID methods in this new claim - could call it - iar = identity assurance request - a list of the methods that work - document types - needs some registry - is “did” registered in iana now?


    REQUIRED. scope parameter value, as specified in Section 3.1.2.


    REQUIRED. Constant string value id_token.


    REQUIRED. Client ID value for the Client, which in this case contains the redirect_uri value of the Client. Since the Client's redirect_uri URI value is communicated as the Client ID, a redirect_uri parameter is NOT REQUIRED to also be included in the request.


    OPTIONAL. id_token_hint parameter value, as specified in Section 3.1.2. If the ID Token is encrypted to the Self-Issued OP, the sub (subject) of the signed ID Token MUST be sent as the kid (Key ID) of the JWE. Encrypting content to Self-Issued OPs is currently only supported when the OP's JWK key type is RSA and the encryption algorithm used is RSA1_5.


    OPTIONAL. claims parameter value, as specified in Section 5.5.


    OPTIONAL. This parameter is used by the Client to provide information about itself to a Self-Issued OP that would normally be provided to an OP during Dynamic Client Registration, as specified in Section 7.2.1.


    OPTIONAL. Request Object value, as specified in Section 6.1. The Request Object MAY be encrypted to the Self-Issued OP by the Client. In this case, the sub (subject) of a previously issued ID Token for this Client MUST be sent as the kid (Key ID) of the JWE. Encrypting content to Self-Issued OPs is currently only supported when the OP's JWK key type is RSA and the encryption algorithm used is RSA1_5.

  6. Kristina Yasuda reporter

    @Tom Jones SIOP V2 draft defines registration parameters that include which subject identifier type RP supports and if it does which DID methods it supports. In the foreseeable future there would not be a mechanism that would allow to resolve any DID method and this information has to be communicated in registration.

    The draft also adds `registration_uri` to allow these parameters to be passed by reference.

    Probably 'vc-supported' parameter should be added to the registration parameters to indicate support for VCs.

  7. Kristina Yasuda reporter

    Another aspect that was brought to my attention that could influence the registration flow is:

    when request object is signed, the initiating party already needs to convey its DID in the JWS header, before ever making contact with a wallet. So SIOP needs to know which DID method RP supports prior to being able to check DID method supported by RP in registration parameter in the request.

  8. Kristina Yasuda reporter

    on 02-16-2021 SIOP special topic call, it was raised that when QR code is used to convey SIOP request to SIOP, it should be signed for integrity protection.

    example scenario: SIOP extracts registration parameters from the req, check if it supports, same signing alg, uses kid in the header to verify the signature of the req and if verified successfully, would continue processing request parameters.

    (encrypting req would not work - SIOP cannot know enc alg RP used, because they are included inside an encrypted req and there is no way to communicate enc alg before hand due to dynamic registration being not available)

  9. Kristina Yasuda reporter

    another clarification made was: registration parameters are included in the req together with other req parameter (such as those asking for claims)

  10. Tom Jones

    I don't get the flows in any way. I am interested in the user experience & i can't see how any of this works. I think i will work on another solution in another environment.

    Be the change you want to see in the world ..tom

  11. Kristina Yasuda reporter

    Another comment received was that this flow is better understood if it is called “Negotiation“ - RP and OP are not pre-registering and storing each other information, rather negotiation and agreeing on the parameters used every single transaction.

  12. Kristina Yasuda reporter

    There is related conversation happening in a thread “[Openid-specs-ab] OpenID Connect Federation updated in preparation for third Implementer’s Draft review“

  13. Kristina Yasuda reporter

    I am ok closing this as this has been superseded by number of issues such as resolvable entity statements and SIOP chooser.

  14. Log in to comment