SIOP Laundry List

The following issue attempts to capture a list of open items around SIOP, following the virtual meetup on the 25/06/20 (https://www.youtube.com/watch?v=ruF1s9jF6_w&feature=youtu.be)

CP - Claims provider (essentially an OpenID Provider)
SIOP - Self Issued OpenID Provider
DID - Decentralised Identifier (https://w3c.github.io/did-core/))

SIOP registration with a claims provider
An SIOP must be able to register with a claims provider in order to request claims, this means a mechanism like dynamic client registration must be supported.
SIOP claims binding the claims provider and SIOP.
In order for the presentation of claims originating from a claims provider being presented from an SIOP to a relying party to be fully trustable, the binding established between the SIOP and claims provider must be robust. One suggested model is documented in (https://mattrglobal.github.io/oidc-client-bound-assertions-spec/)) another approach is described in (https://bitbucket.org/edmund_jay/oidc-claims-aggregation/src/master/OpenID Connect Claims Aggregation.md)..)
SIOP support for attesting keys from the past
This is solved with DIDs, but does there need to be a more generalised solution that does not use DIDs?
Key recovery
To what extend must this be defined by SIOP?
Providing claims to the RP when the SIOP is offline
An expanded version of distributed claims, essentially a form of delegation AS->SIOP->RP so an RP has the ability to contact the AS for claims on the subject. How does the delegation from the SIOP->RP work, is it attenuable i.e does the SIOP request a special access token from the CP for the RP? Is this access token revokable by the SIOP?
Finding the SIOP address
E.g using the siop:// scheme vs other approaches, comparing and contrasting the tradeoffs.
Better support for authenticatable identifiers such as DID's (BREAKING CHANGE)
Currently an SIOP response requires the iss field to be <https://self-issued.me> due to a lack of a better solution at the time. Now with evolving standards such as DID's better solutions exist and this statement could be revised.
Allow for more flexibility around the assertion formats supported in aggregated and distributed claims (BREAKING CHANGE)
Currently as per the chapter all aggregated and distributed claims must be JWT based. Relaxing this constraint would allow other assertion formats used by neighbouring communities to be used. (e.g Verifiable Credentials).
An expanded /userInfo endpoint or a new one (e.g both /aggregation and /credential have been proposed)
To support both backchannel requests made by the SIOP to the claims provider in aggregated claim interactions and requests made by the RP to the CP during distributed claim interactions the CP must have an endpoint available to serve these requests. The endpoint must support the following functionality.
1. Requesting the generation of an assertion specifying the specific claims required (can use the existing claims syntax)
2. Convey the subject identifier to be reported in the generated assertion
3. Convey the audience identifier to be reported in the generated assertion
Support a device flow like interaction model
Supporting a variation in a SIOP response that does not include the SIOP redirecting back to the browser, instead just sending the response. This would involve expanding the supported response modes beyond just fragment.

Relevant links

‌

Comments (10)