[Openid-specs-risc] CAEP/SSE: Event types

[ALI Asad]

One more comment on the token change event. If by token we mean the assertion token/claim sent from IDP to RP after user authentication, then we can see a use case where IDP can send a CAEP message to RP indicating that conditions/assumptions that were true initially, are no longer true. This is explained in use case submitted by Rob Otto, "IDP-Initiated Session Termination".

As such we could keep token event change.

Best regards,
--- Asad

From: Openid-specs-risc [mailto:openid-specs-risc-bounces at lists.openid.net] On Behalf Of ALI Asad via Openid-specs-risc
Sent: Friday, October 23, 2020 4:27 PM
To: openid-specs-risc at lists.openid.net
Subject: [Openid-specs-risc] CAEP/SSE: Event types

Hi all,

Rich Smith and I had a separate discussion on event types; specifically around LoA change event and token change events. Here is what we agreed on. Rich, please chime in and correct/clarify any of these conclusions.


*        LoA change event should be a separate event. The use case it represents are already listed in CAEP Use Cases document and are good indicators to SP. The event should specify which direction the LoA change occurred in. For example, LoA increased or decreased. Also indicated should be the current LoA of course, and perhaps the actual authentication method used (e.g. 2FA using OTP, or PKI or FIDO, etc.).

*        We did not see any overlap between LoA change event and a token change event.

*        Token change event itself is tricky, if it implies a session change. The session is the "last mile" connection between a user and an SP. Any changes in this are only relevant between these two parties; that is user and SP. We could not think of any compelling scenario where  such a change event will be relevant for others. What would be of interest to others is what caused this session state to change. For example, suspicious activity, etc. We should have CAEP events for these things, and they are already in the list of events Tim created.

*        Credential change event should have sub-fields that indicate more context for the event. For example, to indicate that credential change was requested, was successful, or was not successful. As such the credential change event may be sent in pairs; once to indicate start and one to indicate success or failure.

Comments are welcome.

Best regards,
--- Asad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20201027/85eab691/attachment-0001.html>