[Openid-specs-risc] Initial status check is not part of the OpenID SSF CAEP or RISC protocols

[Tim Cappalli]

Hi!

CAEP and RISC are effectively just event dictionaries.

SSF is not designed to communicate runtime state as part of an authentication flow. It is designed to be an async way to share signals between parties when changes occur. This could be "raw contextual signals", such as device compliance information or assurance level changes, or a more opinionated, policy driven signal like "session revoked".

In your example, the IdP and device management service can have an SSF relationship independent of active sessions, and share context between each other as needed.

Hope that helps.

tim

From: Openid-specs-risc <openid-specs-risc-bounces at lists.openid.net> on behalf of Peter Bjork via Openid-specs-risc <openid-specs-risc at lists.openid.net>
Date: Monday, June 19, 2023 at 05:22
To: openid-specs-risc at lists.openid.net <openid-specs-risc at lists.openid.net>
Subject: [Openid-specs-risc] Initial status check is not part of the OpenID SSF CAEP or RISC protocols
Hi all

I’ve not been very active on the OpenID SSF working group meetings, but I have stayed very close to OpenID SSF and followed the development. With that I would like to propose a topic for discussion.

My understanding of the protocols (CAEP & RISC) is that they are mostly focusing on communicating changes that has happened. But what about the initial state check? E.g. a user requests access to a target without an access token, user is sent to an IdP. Now the IdP performs user AuthN and checks if the device is compliant before the IdP issues an assertion. In this flow, for example checking the device compliance, would the IdP and device MGMT system use CAEP/RISC?
My understanding, so far, has been that this initial flow would use something (not CAEP/RISC), but if the IdP learned about a change in device compliance the IdP would then send a CAEP/RISC signal to the target.

Here’s a picture I hope visualizes the gap.
[A diagram of a target  Description automatically generated with medium confidence]


Obviously, this initial status check can be regarding anything, e.g. user risk level. In above example device compliance status is just an example.


Peter Björk
Product Manager, Workspace ONE Access
pbjork at vmware.com<mailto:pbjork at vmware.com>
Twitter: @thepeb

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20230619/b476fd6a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 121077 bytes
Desc: image001.jpg
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20230619/b476fd6a/attachment-0001.jpg>