SIOP Laundry List

The following is a high level summary laundry list of TODO items for a revision to the Self Issued OpenID Provider Chapter from OpenID Connect Core

Terminology

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

1. SIOP registration with a claims provider
   An SIOP must be able to register with a claims provider in order to request claims, this means dynamic client registration must be supported.

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

3. SIOP support for attesting keys from the past
   This is solved with DIDs, but does there need to be a more generalized solution?

4. Key recovery
   To what extend must this be defined by SIOP?

5. Providing claims to the RP with 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.

Outstanding questions
- How does the delegation from the SIOP->RP work, is it atteunatable i.e does the SIOP request a special access token from the CP for the RP? Is this access token revokable by the SIOP?

6. Finding the SIOP address
   E.g using the siop:// scheme vs other approaches, comparing and contrasting the tradeoffs.

7. Better support for authenticatable identifiers such as DID's (BREAKING)
   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.

8. Allow for more flexibility around the assertion formats supported in aggregated and distributed claims (BREAKING)
   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).

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

• Requesting the generation of an assertion specifying the specific claims required (can use the existing claims syntax)
• Convey the subject identifier to be reported in the generated assertion
• Convey the audience identifier to be reported in the generated assertion

10. Support a device flow variation
    Supporting a variation in a SIOP response that does not include the SIOP redirecting back to the browser, instead just sending the response.

Relivant links

• Claims Aggregation
• Client Bound Assertions