Examples that show support for regular OIDC flow

[awoie]

In the examples section, we should probably also add one example that shows support for a normal OIDC flow.

Given the following OIDC auth request:

GET /authorize?
    response_type=code
    &scope=openid%20verifiable_presentation%20
    &client_id=s6BhdRkqt3
    &state=af0ifjsldkj
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb

The above would benefit from the normalization of a new scope verifiable_presentation that indicates that the response will contain a W3C Verifiable Presentation.

Note, if required, one could add the submission_requirements parameter which would result in something like the following:

GET /authorize?
    response_type=code
    &scope=openid%20verifiable_presentation%20
    &client_id=s6BhdRkqt3
    &state=af0ifjsldkj
    &nonce=n-0S6_WzA2Mj
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &submission_requirements=<...>

Currently, the Presentation Exchange spec assumes there is only the distributed claims approach which is not really standardized in the OIDC core spec. It leaves a lot of room how people would interpret "reference". We should still certainly support that.

However, something simpler could also be done. According to OIDC core, the claims can be either included in the id_token or through the user info endpoint. Note, the OIDC code flow concludes with an access_token to access the user info endpoint.

Additionally, the current OIDC examples don't provide verifiable presentations, they only provide verifiable credentials. We could include verifiable presentations by using the client_id as the domain property and nonce | at_hash as the challenge property.

Example using id_token:

{
  "iss": "http://server.example.com",
  "sub": "248289761001",
  "aud": "s6BhdRkqt3",
  "nonce": "n-0S6_WzA2Mj",
  "exp": 1311281970,
  "iat": 1311280970,
  "presentation_submission": { ... },
  "vp": {
      // ...

      "verifiableCredential" : [
          // ...
      ],

      // ... the W3C Verifiable Presentation ...
      "proof" : {
          "challenge": <nonce | at_hash; see auth request above>,
          "domain": <client_id; see auth request above>,
          // ...
      }
  }
}

Example using user info:

{
   "sub": "248289761001",
   // optional presentation submission
   "presentation_submission": { ... },
   "vp": {
      // ...

      "verifiableCredential" : [
          // ...
      ],

      // ... the W3C Verifiable Presentation ...
      "proof" : {
          "challenge": <nonce | at_hash; see auth request above>,
          "domain": <client_id; see auth request above>,
          // ...
      }
}

@OR13 @wyc @csuwildcat any thoughts?

[OR13]

Seems good... I implemented a CHAPI SIOP hacky demo a few weekends ago here: https://github.com/OR13/chapi-siop.did.ai

I would love to take a PR that updated the URIs for SIOP to be more realistic, I didn't put a lot of effort into making them correct, only showing how they might work with CHAPI.

[kimdhamilton]

to discuss 10/7: do we want to bring this in scope?

FYI @csuwildcat @brentzundel

[awoie]

to discuss 10/7: do we want to bring this in scope?

FYI @csuwildcat @brentzundel

IMO, we should. We are working on examples and have already some. We want to wait at least after IIW. We (OIDC4SSI OIDF/DIF WG) want to host a couple of IIW sessions to figure the best way out.

We already have an adopted OIDF draft that shows how to use DIF PE with OIDC: https://openid.net/specs/openid-connect-4-verifiable-presentations-1_0.html independent of the actual OIDC flow.

[kimdhamilton]

agreed; we'll discuss at IIW. @JaceHensley proposed adding a parallel doc with embed examples -- follow up on this

[kimdhamilton]

See Tim's example (note: currently outdated) https://github.com/decentralized-identity/presentation-exchange/issues/101#issuecomment-693701768.

Can close #101 as dupe

[nklomp]

Actually the above example by Tim is for a VP in the id_token and missing the outer verifiable_presentations and claims keys around the presentation_definition. See https://openid.net/specs/openid-connect-4-verifiable-presentations-1_0.html#name-self-issued-openid-provider

The other SIOP flow is using the vp_token (basically the VP itself) in the claims param: https://openid.net/specs/openid-connect-4-verifiable-presentations-1_0.html#name-siop-with-vp_token

The spec is a bit inconsistent and contains some errors (plurals but without arrays and the other way around. How do I know? Because we have a SIOP V2 lib with our PE integrated at: https://github.com/Sphereon-Opensource/did-auth-siop (Still very much a WIP)

[Sakurann]

Thank you, Niels! I was about to make a similar comment. Would be great if you could file issues for the errors in the bitbucket: https://bitbucket.org/openid/connect/issues?status=new&status=open