Create a new section up front to explain the Actors

[Nat Sakimura]

Rationale

In this draft, there are four main actors.

1. User
2. RP
3. OP
4. CP

It is not currently clear for the readers at the outset.

Proposal

The fact and what they are should be explained up-front as New section 5.

The suggested structure for the new Section 5 is as follows:

5. Actors
5.1 User
5.2 RP
5.3 OP
5.4 CP
5.4.1 Claims Endpoint

NOTE 1: It is worth discussing if OP should support Claims Endpoint as well.
NOTE 2: Claims Endpoint should support both ID Token style response and VC. (Distinguished by Media-type?)

6. Interactions
6.1 Introduction (current 5.1)
6.2 Discovery Phase: OP discovering CP Metadata (5.2)
6.3 OP Registration Phase (5.2 bis)
6.3.1 Registration of the OP to the CP
6.3.2 CP obtaining OP metadata and verifying OP issuer value
6.4 Set-up Phase: Obtaining Access and Refresh Token from the CP by the OP (5.3)
6.5.1 OP sending authorization request to CP
6.5.2 User granting access at the CP
6.5.3 CP responds with AT and RT
6.5 RP Phase: An RP requesting claims and receiving them
6.5.1 RP registration to the OP (n/a)
6.5.2 Authentication and Claims request by the RP to the OP (n/a)
NOTE: this is just a regular OIDC authentication request so is ommiteed from the current version. Perhaps needs to be extended for DID/VC.
6.5.3 The User granting access at the OP (n/a)
6.5.4 The OP making down scoped claims request to the CP’s Claims Endpoint
6.5.5 The CP returns the Claims Token
6.5.6 The OP repeats it for all the CPs needed
6.5.7 The OP returns ID Token and UserInfo Response (and potentially Claims Endpoint Response)

7. Security Considerations
8. Privacy Considerations
Bibliography
Appendices

‌

‌

[Kristina Yasuda]

NOTE 2: Claims Endpoint should support both ID Token style response and VC. (Distinguished by Media-type?)

This is where OIDC4VCO draft discussion should be incorporated. At least for the presentation, the current WG preference has been embedding VPs in ID Token or returning them as a separate artifact alongside ID Token or from the userInfo endpoint.

On issuance, embedding VCs in ID Token might be considered as treating ID Token as a new wrapper competing with VP, so for VC, returning them as a separate artifact alongside ID Token or from the userInfo endpoint might be enough.

Note: embedding VPs in ID Token on presentation is necessary for SIOP use-cases.

‌