[Openid-specs-ab] Issue #1180: SIOP Laundry List (openid/connect)

Tobias Looker issues-reply at bitbucket.org
Sun Jul 12 21:29:34 UTC 2020


New issue 1180: SIOP Laundry List
https://bitbucket.org/openid/connect/issues/1180/siop-laundry-list

Tobias Looker:

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](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/\)](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/\)](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\).](https://bitbucket.org/edmund_jay/oidc-claims-aggregation/src/master/OpenID%20Connect%20Claims%20Aggregation.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 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. 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](https://openid.net/specs/openid-connect-core-1_0.html#AggregatedDistributedClaims) 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](https://www.w3.org/TR/vc-data-model/)\).
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](https://www.oauth.com/oauth2-servers/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

* [Claims Aggregation](https://bitbucket.org/edmund_jay/oidc-claims-aggregation/src/master/OpenID%20Connect%20Claims%20Aggregation.md)
* [Client Bound Assertions](https://mattrglobal.github.io/oidc-client-bound-assertions-spec/)

‌




More information about the Openid-specs-ab mailing list