Re: [scim] SCIM Events: Github Issue #26, PR#28 (Input requested)

["Saxe, Dean" <[e-mail]>]

My reasoning is twofold:

First, SCIM is not a protocol for sending security events/signals/data, it’s a protocol for synchronization of resources (human and otherwise) between disparate systems.  Signaling, as described in the draft, is not a security function, it’s a mechanism to ensure that the systems are in sync.  Further, the dradr enables asynchronous processing of bulk updates to the server using SETs to convey the state of the async bulk updates.

Second, the RISC and CAEP protocols sufficiently cover this space and do so with more granularity than is offered in this specification.  CAEP has a well-defined set of credential change signals<https://openid.net/specs/openid-caep-specification-1_0.html#rfc.section.3.3>. RISC profiles signals regarding credential recovery activation<https://openid.net/specs/openid-risc-profile-specification-1_0.html#rfc.section.2.9> and changes to how credential recovery is configured<https://openid.net/specs/openid-risc-profile-specification-1_0.html#rfc.section.2.10>.

I feel that profiling these in the proposed standard would conflict with the work already occurring in the OpenID Foundation specifications which have reached Implementers Draft.

Thanks,
-dhs

--
Dean H. Saxe, CIDPRO<https://idpro.org/cidpro/> (he/him)
Senior Security Engineer, AWS Identity Security Team | Amazon Web Services (AWS)
E: [e-mail]<mailto:[e-mail]> | M: 206-659-7293<tel:[phone]>

From: scim <[e-mail]> on behalf of Phillip Hunt <[e-mail]>
Date: Sunday, December 10, 2023 at 2:24 PM
To: SCIM WG <[e-mail]>
Subject: [EXTERNAL] [scim] SCIM Events: Github Issue #26, PR#28 (Input requested)


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.


Dean has requested that SCIM Signals be removed from the specification as they duplicate RISC specifications published by OpenID Foundation. WG input is requested:
References:
[cid:image001.png@01DA2C49.B2CF5D60]

Privacy considerations - Risk Signals Events · Issue #26 · ietf-scim-wg/draft-ietf-scim-events<https://github.com/ietf-scim-wg/draft-ietf-scim-events/issues/26>
github.com<https://github.com/ietf-scim-wg/draft-ietf-scim-events/issues/26>


[cid:image002.png@01DA2C49.B2CF5D60]

Removed authMethod/pwdReset from IANA registry by dhs-aws · Pull Request #28 · ietf-scim-wg/draft-ietf-scim-events<https://github.com/ietf-scim-wg/draft-ietf-scim-events/pull/28>
github.com<https://github.com/ietf-scim-wg/draft-ietf-scim-events/pull/28>




This request means removing section 2.5.  A copy of that section is posted below.

Reasons to have Section 2.5:

1.  A provisioning endpoint such as SCIM may be the originating source of the security signal.  The events expressed using SCIM Identifiers rather than OpenID’s much more complex system (which uses per feed configurable identifiers).
2.  Because of signing requirements, a SCIM Signal might get republished as part of a larger or different security signals system before distributing to a third party.  For example, the SCIM subject identifier is translated along with the event into a proper RISC event. This may be done, because the SCIM system doesn’t have the full OIDC context of the resource (e.g. because they may run off a different identity data store)
3. Authentication factor changes and password resets might trigger other provisioning workflows.
4. Changes to authentication attributes not typically propagated as provisioning events because the raw values are not and should not be made available.

I am neutral on this issue. I can see both sides of the concern.

Please reply with your comments and indicate:

YES - Please remove section 2.5 SCIM Signals Events

NO - Please leave section 2.5 as is (or with proposed changes)

Thanks,

Phil
[e-mail]

Section 2.5

2.5.  SCIM Signals Events

   This section defines security signal events that have occurred within
   a SCIM Service Provider.  The URI prefix for these events is:
   urn:ietf:params:SCIM:event:signal

2.5.1.  urn:ietf:params:SCIM:event:sig:authMethod

   A new authentication method has been added to the User profile.  As
   attackers often use new authentication methods to lock-out Users from
   their account, this signal can be used by the receiver that the
   chance of account them may be temporarily elevated.  The receiver MAY
   also wish to take action such as resetting current authorizations or
   sessions.

   {
     "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
     "sub_id": {
       "format": "scim",
       "uri": "/Users/44f6142df96bd6ab61e7521d9"
     },
     "events":{
       "urn:ietf:params:SCIM:event:sig:authMethod": {}
     },
     "iat": 1458496025,
     "iss": "https://scim.example.com"
   }

         Figure 12: Example SCIM Authentication Factor Change Event

2.5.2.  urn:ietf:params:SCIM:event:sig:pwdReset

   The specified resource (e.g.  User) has changed its password or the
   password has been reset.  When the password has changed, the
   attributes attribute is supplied with the value "password".

   {
     "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
     "sub_id": {
       "format": "scim",
       "uri": "/Users/44f6142df96bd6ab61e7521d9"
     },
     "events": {
       "urn:ietf:params:SCIM:event:sig:pwdReset": {}
     },
     "iat": 1458496025,
     "iss": "https://scim.example.com",
     "aud":[
       "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
       "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
     ]
   }

               Figure 13: Example SCIM Password Change Event