Can RPs getting back to the right SIOP the second time?

[Kristina Yasuda]

During 2021-Nov-04 Connect call the question was raised, how do RPs get back to the right SIOP after they have interacted with one or multiple SIOPs previously.

Given “login with SIOP“ would be listed under “login with password“/”login with WebAuthn”, it was suggested that RP could tie username to the option “login with SIOP“ and a particular SIOP provider’s authorization_endpoint (ie custom schema/universal links/app links). Thereby being able to generate a request_uri targeting that user’s selected provider’s SIOP instance.

It was noted that universal links/app links are one per SIOP provider and not per SIOP instance, so

This is related to Issue #1352, since if there is a way for the RP to reach particular SIOP more than once, it can use encrypted id_token_hint with that SIOP’s cached public key (sub).

[David W Chadwick]

If VCs are being used, then getting back to the “right” SIOP is irrelevant. The whole point of VCs is that the Issuer identifies the user to the RP. (The SIOP is just a protocol engine for passing the VCs from the holder to the RP.) So the real question should be “how can the RP get back to the same user each time?” The answer is simple. The RP gets the same VCs from the same issuers each time. This is a new mindset and a new paradigm - one that is focussed on IDENTITY and not on IDENTIFIERs. So the RP is not interested in getting back a username that it (or someone else issued) - unless that username is presented as a unique identifier in a VC. Instead the RP is interested in getting back the same identity each time. This is comprised of a set of identity attributes that together uniquely identify each user. In the simplest case there only needs to be one VC containing one unique identifier (e.g. email address), but this is the degenerate case of the broader concept.

[Tom Jones]

I dislike the name of this issue as it can be confused with the central myth of DID as represented by David’s response. This myth is that there is no enduring relationship between the user and the web site. This myth is such an edge case that i am surprised that it still survives. I would propose that we cannot create a single standard that encompasses both the DID myth and the reality of enduring relationships.

[David W Chadwick]

In my mental (and implemented) model there is an enduring relationship between the user and the RP, and this is based on the identity attributes of the user (as asserted in the VCs from the trusted issuers). It is not based on a transient DID that is assigned for each session and to which the user’s short lived VCs are bound. Each DID merely represents the user’s ephemeral public key that is being used for the current session.

[Tom Jones]

An attack on this is trivial. Just get the same attributes in a VC from some trusted source and use it to “sign-in” to the RP. AFAIK the use of attribute-base authentication is no longer considered to have any high-level of assurance. Even the use of the smart phone as a second factor is just another form of attribute-base authentication that is surprisingly easy to attack.

[David W Chadwick]

Tom, your assertion is correct if the attributes do not uniquely identify the user within the RP’s context. But if they do, then it is not possible for an imposter to get the same set of attributes from any trusted source (by definition).

[David W Chadwick]

P.S. if on the other hand the RP wants to create a group account for, say, all members of dept X, then any member of this department would be able to access that account by providing the “department X” VC (along with their unique subject ID).

[Stephane Durand]

This is a new mindset and a new paradigm - one that is focussed on IDENTITY and not on IDENTIFIERs. So the RP is not interested in getting back a username that it (or someone else issued) - unless that username is presented as a unique identifier in a VC.

David, I am not sure there is a real difference between the two paradigms (or I fail to grasp it), as the RP will quite likely request a set of identity attributes from the user and build a compound identifier from it in the general case (in France, we have a federated login system that does something similar), and in the case of a RP-issued VC that contain a RP-scoped username, we’re completely in the identifier paradigm.

My take of your VC-centric approach is that is quite suitable for “guest login” where the relationship between the RP and the user is much more based some attribute / capacity that the user can prove than a registered account.

‌

My general concern with this issue is that from previous discussions, I build the understanding that while SIOP can be used to provide presentations that are self-contained proofs (which can be considered one-time operations), it may not be suitable to identify/authenticate a user for a RP (where the need to get the same SIOP a second time would lie). The discussions pointed the reliance on unbound channels or inability to verifiably identify a SIOP instance to transitively let it identify the user.

[David W Chadwick]

Stephane. Sorry but I do not understand your issue. If a one-time self contained proof can uniquely identify and authenticate the user to the RP, then why cannot this process be repeated multiple times to identify the same user to the RP multiple time. In this way it would not matter whether the user is using the same SIOP or a different one would it? Today I login to my RP accounts from different browsers, but the RP always recognises me regardless of which browser I chose to use.

[Stephane Durand]

David.

If a one-time self contained proof can uniquely identify and authenticate the user to the RP,

My concern is the same as presented in Issue 1299: RP needs to authenticate a user in a specific context, not just any (random) user, where context can translate as “in this web session”, “in front of this front-end terminal I control”…

What I meant with “self-contained” is that with a presentation, you have a set of signed evidences which are signed together by their holder. You can then deduce any proof as a combination of these evidences. But there is no evidence related to the context with the RP in the presentation, so the RP cannot rely solely on the presentation to authenticate the user: with the VP, RP knows that the user answering is who they pretend they are but it doesn’t know if the user answering is the one it that belong to this context.

(Getting back at it, “self-contained” was a poor choice of terms since I wanted to stress the fact that the proof didn’t extend beyond to its content, and in particular to the context the RP and the user were sharing).

Then, provided that “if” is somehow satisfied, I agree with the your statement

[David W Chadwick]

Stephane. if the the RP sends the specific context to the SIOP at the start of the session, and this is passed to the wallet by SIOP, and the wallet puts the context in the VP and signs it, then doesn’t this bind the VP to the current context and provide what you need? If not, why not?

[David W Chadwick]

p.s. the authenticate part of your requirement is provided by transitive trust. The OP(VC Issuer) is trusted by the RP to authenticate the user. The OP creates a VC for the user to identify the user, and places the user’s public key (or DID) into the VC to authenticate the user. The user signs the VP with the corresponding private key, and if the VP is bound to the RP’s session as above, before it is signed, then the RP can trust the OP to authenticate the user’s public key (or DID) and can trust the user to authenticate with the private key signing the VP encapsulating the VC.

‌

‌

[Stephane Durand]

if the the RP sends the specific context to the SIOP at the start of the session, and this is passed to the wallet by SIOP

I agree, but this implies that the SIOP / user is able to validate the session as being the correct one (not spoofed by an attacker) before signing the VP containing it. I’m not saying it’s impossible, but so far, no satisfying idea came to my mind as to how the SIOP can do this. Then it means that it’s the user that should validate that the session is the correct one, and unless we can present the session information in a clear and discriminate enough way, I don’t think it’s reasonable to expect the user to endorse this responsibility.

It’s transitive trust indeed but one transition is not trusted in my opinion (the one that connects the RP to the specific instance of SIOP that is relevant to the context) so the authentication as a whole cannot be trusted.

Maybe this discussion is diverging with the original question and should continue in the other issue thread I linked?

[David W Chadwick]

So is your primary concern now a phishing attack? It sounds like it. But the title of this issue implied the opposite i.e. a spoofed SIOP/wallet.

If the user starts the connection to the RP, and is tricked into connecting to a fake RP, then isn’t this out of scope of OIDC? I dont see how we can protect against this, do you?

[Stephane Durand]

No. The RP is genuine all along. Only the context is not the correct one. The closest type of attach I can think of a “session hijacking” except that what is hijacked is not the session but the identification token that will serve for the RP to associate an identity its manages with a session. And since SIOP defines the mechanism through which the identification token is delivered, I say this is full in the scope.

‌

Back to the OP issue:

It was noted that universal links/app links are one per SIOP provider and not per SIOP instance

Maybe there’s a different underlying model considered, but I associate a SIOP instance one-to-one with an application. Also, with universal links, one associates an URL with an application id (in the sense of the mobile platform), not with the publisher of the application, so I’d rather expect to read that universal links are one per SIOP instance.

Is it considered in this issue that we could have more than one instance of the same SIOP application deployed on the same device? Or is there a different meaning to read in “SIOP instance”?

[Kristina Yasuda]

I am not sure there is a need to add any specification text to clarify this? (cc @Torsten Lodderstedt @Michael Jones @George Fletcher )

If not, I’m ok closing this one

[Kristina Yasuda]

using universal link/app link is the answer