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.