a session on the RP with the same key

[adeinega]

Section "Federated sessions" states that

If the key is correct, the user agent will create a session on the RP with the same key as the SP.

What should happen when this key is provided by the SP (1) but it's incorrect (2)? The spec doesn't describe this, implying that the user agent will create a new session on the RP.

However, isn't this an indication the user's device was compromised?

My understanding that the SP has no reason to pass some junk as key's value, it does it only when it has a valid DBSC session, right?

[drubery]

What should happen when this key is provided by the SP (1) but it's incorrect (2)? The spec doesn't describe this, implying that the user agent will create a new session on the RP.

I think there might be a little confusion about the parties involved here. The RP provides a hash of a key, not the SP. Since it's the hash of a key, and not the public key itself, the user agent can't create a new session on the RP with that key.

You're right that we don't fully specify the behavior in section 3.3 (it's a "Privacy Considerations" section). Step 4.12 of https://w3c.github.io/webappsec-dbsc/#algo-create-session-key-pair says that we fail to create a key pair if the keys do not match. This leads to the user agent not registering any session at all on the RP.

[adeinega]

Yes, the SP needs to share a hash of a key with the RP in some way... this is my understanding. I guess one way to do this is by passing it as one of the claims in an OpenID Connect ID Token, and OpenID Connect providers have no reason to provide some incorrect value instead of a valid hash.

This leads to the user agent not registering any session at all on the RP.

I’m curious if there’s anything else that user agents could do in addition to that (to protect end users). I've also found some more text on this in section 5.

Sites using federated login with DBSC (see § 3.3 Federated sessions) should ensure that only sessions with the federated key are accepted. Security of federated sessions relies on the machine being uncompromised at Session Provider (SP) login, since malware can use temporary access to the machine to register a session on the Relying Party (RP) with new keys. Therefore RPs should only accept sessions registered with the appropriate public keys they received from the SP.

[drubery]

Can you give more details on the threat model you're thinking about? I'm not clear if the attacks you're thinking about involve malicious SPs or malware on device.

[adeinega]

I'm simply reading and researching the spec, especially the federated sessions parts, and these Qs immediately come up to mind.

In my eyes, it’s suspicious when an IDP has a valid authentication & DBSC session, it wants to reuse the key to avoid creating new keys per RP, communicates a (valid) hash of the key to an RP and it doesn’t “actually” recognize it.

Maybe, just maybe, an IdP should be aware about that, or perhaps the user agent needs to do something more, as at this moment, it silently doesn’t start a new session.