[OIDC4CI] use-case when the user is already logged in before starting the issuance

[Kristina Yasuda]

In the current draft, authentication of the user happens after the Issuer receives the authentication request. However, there are use-cases where the user is already signed in prior to sending the authentication request.

In those cases, the most straight forward option would be for the RP to send id_token_hint/login_hint in the authentication request. However, when the RP is SIOP, in most cases, SIOP would not have an ID Token, so there would be a need for the Issuer to pass the id_token_hint/login_hint to the RP beforehand. This is aligned with section 4 of OIDC.Core Initiating Login from the third party.

Clarification: id_token_hint/login_hint will not be used by the OP to log in the user anew, but to know which session to work with

[Tom Jones]

I don't understand the use case for “ when the RP is SIOP“

why would that ever happen?

[Thomas Bellebaum]

@Tom Jones In OIDC4CI, a Wallet is acting as either a RP and a SIOP, depending on the protocol step.
For example, in the PR by @Torsten Lodderstedt , the Issuer is calling (=redirecting to) a wallet endpoint to tell it to initiate the issuance, which then calls the Issuer for authentication, at which point the issuer may again call the wallet to request verifiable presentations. The lines become blurry here :)

@Kristina Yasuada Couldn’t the Issuer just keep a session for the logged in user? A wallet may then be instructed to use the prompt request parameter to indicate that it only wishes to work with an already authenticated user.

[Tom Jones]

i cant parse that sentence on the RP in any meaningful way. I guess the idea is that the wallet has the ability to “log onto” the issuer to get a credential. BUT the issuer needs to get the subject of the credential so the issuer would need “log onto” the wallet (in HTTPS sense of log on) in order to prove the identity of the wallet. So would issuer then be the client of the wallet? Using client and RP makes no sense at all here. Why not just use didcomm terminology which is peer-peer rather than openID / oauth terminology which is not peer-peer? There is no way this can be considered to be a rest-full transaction.

[Kristina Yasuda]

addressed in PR #98

[Tom Jones]

i guess the point here is that anywhere a jwt is issued, it could be a vc?

[Kristina Yasuda]

resolved by PR #98