[Openid-specs-ab] Issue #1436: Mental Models (openid/connect)

[David Chadwick]

New issue 1436: Mental Models
https://bitbucket.org/openid/connect/issues/1436/mental-models

David Chadwick:

I am sure we all have our own mental models of how SIOPv2 works, with or without OIDC4VPs. We are discussing various issues around sub, id-token, issuer etc. based on our implicit mental models. However, due to the incompatibilities between these models, this might explain why it is difficult to resolve several of the current issues. The suggestion is that we should make these mental models explicit, because it should then help us to resolve various outstanding issues.

This is an initial incomplete list of possible mental models that people might have in mind. It would be greatly appreciated if people could add their own model to the ones below.

1. SIOPv2 only

    1. The RP allows the user to self identify, and uses the sub key as a means of authenticating the user each time they login \(similar to the FIDO model\). All claims are self issued.
    2. The RP already has a set of user accounts and allows an existing user to login to it, then allows the user to link their SIOPv2 key with this account. Now the user can use SIOP or the existing mechanism to log in to the RP.
    

2\. SIOPv2 with OIDC4VP

In this case the RP will need to have a policy listing which VC issuers it trusts to issue which claims, and this will be transferred to the SIOP using DIF PE.

1. The user has a DID and uses this to obtain long lived VCs from multiple Issuers. The SIOP uses the same DID in the sub claim to identify the subject. The RP should store the long lived VCs on first registration, and check if they have been revoked each time the user logs in with the DID \(and without re-presenting the VCs\).
2. The user has multiple DIDs, one for each VC Issuer, and uses these to obtain long lived VCs. The user creates a different key pair for SIOP and uses this in the sub claim. The RP should store the long lived VCs and sub key on first registration, and check if the VCs have been revoked each time the user logs in with the sub claim.
3. The user creates a transient key each time she contacts an RP, and based on the RP’s policy carried in PE, asks the VC Issuer\(s\) to create selectively disclosed short lived VC JWTs for the RP according to the RP’s requirements. The sub claim and VCs hold this key and it will not be used again for subsequent login. The RP does not need to store the short lived VCs for subsequent verification, nor check any revocation lists. The RP creates a user account based on the user’s identity from the VCs.
4. The user has multiple DIDs, one for each VC Issuer, and uses these to obtain short lived selectively disclosed VCs on demand, based on the RP's policy carried in PE. The user also has a long lived SIOP key that is used for multiple logins. The RP does not need to store the short lived VCs nor check any revocation lists, and can match the user’s account based on the sub claim, and check that the user’s identity is still valid based on the short lived VCs. 

I am sure there are other mental models that people have, and it would be good to record them here so as to document a complete list.

Incompatibilities between these models are at least:

1. the id token may or may not contain additional user claims besides the sub claim
2. the sub claim may or may not be reused for subsequent login
3. there may or may not be a vp token identifying the user
4. the RP may have to check multiple user keys or a single key   
5. JWK thumbprints may or may not be required.
6. <add your own incompatibility here>

‌