Closed dhs-aws closed 7 months ago
Agreed they are duplicative. What do we do about risc’s difference in subject identifiers?PhilPhilOn Nov 27, 2023, at 10:37 AM, Dean H. Saxe - AWS Identity @.***> wrote: This section describes a signal regarding changes to the users authentication mechanisms. However, it does not describe the changes, just that a change has occurred and that some further action may need to take place when received. I see a few issues with the proposed signal. First, credential change signals are defined by CAEP and RISC. These are security event profiles which seem more aligned with where I would expect such events to be profiled. https://openid.net/specs/openid-caep-specification-1_0.html#rfc.section.3.3 https://openid.net/specs/openid-risc-profile-specification-1_0.html#rfc.section.2.9 Specifically, CAEP not only provides a change event but the nature of the event as well. RISC allows for events indicating that account recovery has been initiated. These events are more fully described and provide sufficient information for receivers to process the event and determine next steps. Conversely, the event described in this document only describes that a new authN method has been added. Similarly, 2.5.2 describes a password reset event, but it does not sufficiently describe an event for non-password based mechanisms. Again, CAEP and RISC cover these events more fully by describing specific credential change and account recovery events which give a more complete view of the world. I recommend that the proposed standard align with the events profiled in CAEP and RISC.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>
Agreed they are duplicative. What do we do about risc’s difference in subject identifiers?PhilPhilOn Nov 27, 2023, at 10:37 AM, Dean H. Saxe - AWS Identity @.***> wrote: This section describes a signal regarding changes to the users authentication mechanisms. However, it does not describe the changes, just that a change has occurred and that some further action may need to take place when received. I see a few issues with the proposed signal. First, credential change signals are defined by CAEP and RISC. These are security event profiles which seem more aligned with where I would expect such events to be profiled. https://openid.net/specs/openid-caep-specification-1_0.html#rfc.section.3.3 https://openid.net/specs/openid-risc-profile-specification-1_0.html#rfc.section.2.9 Specifically, CAEP not only provides a change event but the nature of the event as well. RISC allows for events indicating that account recovery has been initiated. These events are more fully described and provide sufficient information for receivers to process the event and determine next steps. Conversely, the event described in this document only describes that a new authN method has been added. Similarly, 2.5.2 describes a password reset event, but it does not sufficiently describe an event for non-password based mechanisms. Again, CAEP and RISC cover these events more fully by describing specific credential change and account recovery events which give a more complete view of the world. I recommend that the proposed standard align with the events profiled in CAEP and RISC.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>
Agreed they are duplicative. What do we do about risc’s difference in subject identifiers?PhilPhilOn Nov 27, 2023, at 10:37 AM, Dean H. Saxe - AWS Identity @.***> wrote: This section describes a signal regarding changes to the users authentication mechanisms. However, it does not describe the changes, just that a change has occurred and that some further action may need to take place when received. I see a few issues with the proposed signal. First, credential change signals are defined by CAEP and RISC. These are security event profiles which seem more aligned with where I would expect such events to be profiled. https://openid.net/specs/openid-caep-specification-1_0.html#rfc.section.3.3 https://openid.net/specs/openid-risc-profile-specification-1_0.html#rfc.section.2.9 Specifically, CAEP not only provides a change event but the nature of the event as well. RISC allows for events indicating that account recovery has been initiated. These events are more fully described and provide sufficient information for receivers to process the event and determine next steps. Conversely, the event described in this document only describes that a new authN method has been added. Similarly, 2.5.2 describes a password reset event, but it does not sufficiently describe an event for non-password based mechanisms. Again, CAEP and RISC cover these events more fully by describing specific credential change and account recovery events which give a more complete view of the world. I recommend that the proposed standard align with the events profiled in CAEP and RISC.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>
Agreed they are duplicative. What do we do about risc’s difference in subject identifiers?PhilPhilOn Nov 27, 2023, at 10:37 AM, Dean H. Saxe - AWS Identity @.***> wrote: This section describes a signal regarding changes to the users authentication mechanisms. However, it does not describe the changes, just that a change has occurred and that some further action may need to take place when received. I see a few issues with the proposed signal. First, credential change signals are defined by CAEP and RISC. These are security event profiles which seem more aligned with where I would expect such events to be profiled. https://openid.net/specs/openid-caep-specification-1_0.html#rfc.section.3.3 https://openid.net/specs/openid-risc-profile-specification-1_0.html#rfc.section.2.9 Specifically, CAEP not only provides a change event but the nature of the event as well. RISC allows for events indicating that account recovery has been initiated. These events are more fully described and provide sufficient information for receivers to process the event and determine next steps. Conversely, the event described in this document only describes that a new authN method has been added. Similarly, 2.5.2 describes a password reset event, but it does not sufficiently describe an event for non-password based mechanisms. Again, CAEP and RISC cover these events more fully by describing specific credential change and account recovery events which give a more complete view of the world. I recommend that the proposed standard align with the events profiled in CAEP and RISC.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>
I believe it must be up to the client and server to determine how to handle the different subject identifiers. This is not a SCIM issue or a CAEP/RISC issue, it's an issue that transcends both.
Signals events were removed in draft 04.
This section describes a signal regarding changes to the users authentication mechanisms. However, it does not describe the changes, just that a change has occurred and that some further action may need to take place when received.
I see a few issues with the proposed signal.
First, credential change signals are defined by CAEP and RISC. These are security event profiles which seem more aligned with where I would expect such events to be profiled. https://openid.net/specs/openid-caep-specification-1_0.html#rfc.section.3.3 https://openid.net/specs/openid-risc-profile-specification-1_0.html#rfc.section.2.9
Specifically, CAEP not only provides a change event but the nature of the event as well. RISC allows for events indicating that account recovery has been initiated. These events are more fully described and provide sufficient information for receivers to process the event and determine next steps. Conversely, the event described in this document only describes that a new authN method has been added.
Similarly, 2.5.2 describes a password reset event, but it does not sufficiently describe an event for non-password based mechanisms. Again, CAEP and RISC cover these events more fully by describing specific credential change and account recovery events which give a more complete view of the world. I recommend that the proposed standard align with the events profiled in CAEP and RISC.