SIOP Laundry List

Issue #1180 new
Tobias Looker created an issue

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/))

  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 a mechanism like 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 generalised solution that does not use DIDs?
  4. Key recovery
    To what extend must this be defined by SIOP?
  5. 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?
  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 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.
  8. 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).
  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.

    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
  10. 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 (6)

  1. Tom Jones

    while i support discussion of these issues in some openID forum, it works better if each issue has its own issue number.

    I am working on implementations that support DIDs but do not take a dependency on them so i would encourage more generic terms. For example issue 1081 speaks to the issue of a persistent user id that could handle the DID as well as other solutions. Since the DID is a URL/URN that should add not complexity to a DID only implementation.

    I would like to see OpenID commitment to generating a doc (spec, whatever) that specifies an ecosystem where self-issues ID are encouraged. This the the topic of issue 1175,

    Specifically addressing item 1 of this list the CP - in the US NIST SP’s we have the idea of a Credential Service Provider. My implementations support this for a variety of claims, such as (A) identity, (B ) authentication and (C) federation assurances. I suspect this falls under the concept of CP in the above, but would like to see that made clear for orgs that follow the NIST publications.

  2. Tobias Looker reporter

    @Tom Jones since you have been working on your draft around key recovery can you open a seperate issue and link your draft for issue number 4 mentioned above?

  3. Tobias Looker reporter

    Issue 3 and 7 are also intrinsically linked as the proposed resolution to 3 could be to leverage decentralized identifiers

  4. Log in to comment