Mental Models

[David W 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>

‌

[Kristina Yasuda]

I think the most fundamental distinction that should be made in all of these conversations is distinguishing between user authentication and sending claims about the user, where user authentication equates to which identifier, the OP uses to maintain relationship with the user.

This has also been discussed in Connect call, see https://bitbucket.org/openid/connect/issues/1434/dubious-support-for-authentication#comment-61839114

I am not sure “mental model“ is the most accurate word, I would use “architecture“, or “design choice” or something, but the summary is as follows:

Architecture	User Authentication	sending claims about the user
1. usual OIDC	sub of the ID Token, within the iss's context	claims attested by the OP; sent inside the ID Token, userInfo Endpoint
2. SIOP v2 only	sub of the ID Token, within self-issued context	self-attested claims; sent inside the ID Token
3. SIOP v2 + OIDC4VP	sub of the ID Token (or potentially user identifier from VC/VP - needs discussion) (please do not use user claim in VC as an identifier)	self-attested claims if sent inside the ID Token; and/or claims attested by an entity/issuer that the RP trusts (if this issuer = OP, better use usual OIDC model)
4. usual OIDC + OIDC4VP	sub of the ID Token (using user identifier from VC/VP would not make sense if usual OP is used)	claims attested by the OP; sent inside the ID Token, userInfo Endpoint claims attested by an entity/issuer that the RP trusts (if this issuer = OP, better use usual OIDC model)

I would not call differences of each architecture optimized for a certain use-case “incompatibilities“.

[Kristina Yasuda]

putting SIOP label for the tracking purposes

[Kristina Yasuda]

During 2022-Feb-17 SIOP call, we agreed to give people one week to read, digest, and comment to discuss at the next week’s SIOP call.

[Tom Jones]

Purpose is a good field to have - not sure why it needs to be modified with tracking.

[Jo Vercammen]

I agree that we speak about a mental model. As it is described , at the moment, an interpretation of the specification by Somebody. I due think that the end-result need to be communicated as either architecture. Because, it quite factual right?
Personally, I don’t have much feedback or remarks. Except for one, If I read the ticket from David. It looks that we need to use DID’s in the sub in case of SIOP v2 + OIDC4VP? I thought that we could use in any design choice either JWK Thumbprint or DID’s for the Subject Types

I like the approach of Kristina to display it in a table format.

[David W Chadwick]

@Jo. I did not intend my list to be the complete set of models. It was just my first cut. So if you are proposing the use of DIDs and JWK Thumbprints for SIOPv2 only then please feel free to add this model to the list (along with its implications)

[David W Chadwick]

@Kristina. You said “where user authentication equates to which identifier, the OP uses to maintain relationship with the user.” Whilst I agree with this statement, to me this does not imply

a) that the OP and SIOP are the same entity. In fact in the case of SIOP they are different, as traditional OPs (==IdPs) are trusted by RPs (and share the same user ID) whereas SIOPs (NE IdP) are not necessarily trusted. Trust (in the case of SIOPv2 with OIDC4VP) is with the VC Issuer (== IdP).

b) that in the SIOPv2 with OIDC4VP case, the same identifier is used between the user and OP (== IdP == VC Issuer) and between the user and RP. Particularly in the case of pairwise identifies, they will be different. However the same ID will be shared by the user, SIOP and RP.

[Kristina Yasuda]

what you stated in a) is exactly where our mental models diverge. In the case of SIOPv2, the trust regarding user authentication is with the user and the SIOP application it uses, not the VC Issuer. Trust in the VC Issuer comes into when verifying the user claims, and that’s separate from the user authentication.

[Kristina Yasuda]

wrt b) I think we agree. I am exactly saying that user identifier between user and the VC Issuer (VP) is different from the one btw the user and the RP (ID Token)

[David W Chadwick]

@Kristina. wrt a) I think that actually we do agree. What you are calling trust in user authentication, I think of as trust in PoP of a private key corresponding to the presented public key. However if this is the first exchange, the RP has no knowledge about the identity of the user, and therefore “authentication” of the user (in the NIST meaning “Verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in an information system” https://csrc.nist.gov/glossary/term/authentication) is a moot point as the user could be anyone, so has not really been authenticated as they have not been identified. RPs that wish to identify the user rely on the IdP (=VC Issuer). Trust in identification comes from the IdP, and so trust in authentication also comes from the IdP. All the user is doing is proving that the VCs belong to him/her i.e. PoP.

I think this shows the importance of clarifying our mental models.

P.s. I agree that in subsequent exchanges, once the RP has identified and authenticated the user, then the id-token alone may be sufficient to authenticate the user (but not necessarily, e.g. if the user’s attributes at the IdP have been modified or revoked, then the identity of the user has changed).

‌

[David W Chadwick]

@Kristina. Wrt b). Unfortunately we do not agree. You are saying the user identifier is always different. I am saying that they can be the same or can be different. We cannot make any assumptions about this.

[David W Chadwick]

I am not sure that we all have the same mental models yet because we may disagree on what authentication is.

1. Authentication to some is simply knowing it is the same entity each time, regardless of its identity (as in FIDO).

2. Authentication to others (including NIST) is identification followed by verification.

I think the second is a subset of the first. If SIOPv2 uses the first, then it may not be able to use the second without some modifications to it, due to the stricter requirements of the second.

[David W Chadwick]

However, because OIDC4VP can now be used independently of SIOPv2, and OIDC4VP uses the second form of authentication, then there is a solution to this issue - do not use SIOPv2, use OIDC4VP on its own.

[Kristina Yasuda]

closing upon David's consent