Registration in SIOP
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)
-
-
In the call today, John and Tobias pointed out that we could look at Credman https://w3c-ccg.github.io/credential-handler-api/
-
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?
-
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.
-
That works with the existing OIDC section 7. Two issues:
- 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.
- 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.
-
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?
scope
REQUIRED.
scope
parameter value, as specified in Section 3.1.2.response_type
REQUIRED. Constant string value
id_token
.client_id
REQUIRED. Client ID value for the Client, which in this case contains the
redirect_uri
value of the Client. Since the Client'sredirect_uri
URI value is communicated as the Client ID, aredirect_uri
parameter is NOT REQUIRED to also be included in the request.id_token_hint
OPTIONAL.
id_token_hint
parameter value, as specified in Section 3.1.2. If the ID Token is encrypted to the Self-Issued OP, thesub
(subject) of the signed ID Token MUST be sent as thekid
(Key ID) of the JWE. Encrypting content to Self-Issued OPs is currently only supported when the OP's JWK key type isRSA
and the encryption algorithm used isRSA1_5
.claims
OPTIONAL.
claims
parameter value, as specified in Section 5.5.registration
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.
request
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 thekid
(Key ID) of the JWE. Encrypting content to Self-Issued OPs is currently only supported when the OP's JWK key type isRSA
and the encryption algorithm used isRSA1_5
. -
- changed status to open
-
reporter - changed title to Registration in SIOP
-
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.
-
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.
-
reporter related to Issue
#1199Which wallet gets invoked in SIOP https://bitbucket.org/openid/connect/issues/1199/which-wallet-gets-invoked-in-siop -
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)
-
reporter another clarification made was: registration parameters are included in the req together with other req parameter (such as those asking for claims)
-
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
-
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.
-
reporter There is related conversation happening in a thread “[Openid-specs-ab] OpenID Connect Federation updated in preparation for third Implementer’s Draft review“
-
reporter - changed status to resolved
I am ok closing this as this has been superseded by number of issues such as resolvable entity statements and SIOP chooser.
- Log in to comment
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