Re: [scim] scim over messaging

Chris Hyzer <mchyzer@isc.upenn.edu> Wed, 14 October 2015 13:46 UTC

Return-Path: <mchyzer@isc.upenn.edu>
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677F51A802D for <scim@ietfa.amsl.com>; Wed, 14 Oct 2015 06:46:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.543
X-Spam-Level:
X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ao1ZGKQsIBXz for <scim@ietfa.amsl.com>; Wed, 14 Oct 2015 06:45:57 -0700 (PDT)
Received: from exch-chub01.exchange.upenn.edu (exch-chub01.exchange.upenn.edu [128.91.3.42]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86AC1A702A for <scim@ietf.org>; Wed, 14 Oct 2015 06:45:56 -0700 (PDT)
Received: from exch-mbx01.exchange.upenn.edu ([fe80::10fd:fb9c:1d0c:81a6]) by exch-chub01.exchange.upenn.edu ([fe80::821:cd33:1a58:3fdd%11]) with mapi id 14.03.0235.001; Wed, 14 Oct 2015 09:45:52 -0400
From: Chris Hyzer <mchyzer@isc.upenn.edu>
To: Phil Hunt <phil.hunt@oracle.com>
Thread-Topic: [scim] scim over messaging
Thread-Index: AdEF8c3fBlbEgTnzTZCHJHgvVQL+ygAI6tyAABw3/OA=
Date: Wed, 14 Oct 2015 13:45:52 +0000
Message-ID: <04BE669BEE19E54BBDC2A9A2585BB688A7A3BB37@exch-mbx01.exchange.upenn.edu>
References: <04BE669BEE19E54BBDC2A9A2585BB688A7A3B3D4@exch-mbx01.exchange.upenn.edu> <8121CE8E-9574-4D3E-B757-BC3CA0676D33@oracle.com>
In-Reply-To: <8121CE8E-9574-4D3E-B757-BC3CA0676D33@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.91.219.176]
Content-Type: multipart/alternative; boundary="_000_04BE669BEE19E54BBDC2A9A2585BB688A7A3BB37exchmbx01exchan_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/scim/GlQ1QknxSJ_UsxYmS71Ss6ix3ps>
Cc: "scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] scim over messaging
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF <scim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scim>, <mailto:scim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/scim/>
List-Post: <mailto:scim@ietf.org>
List-Help: <mailto:scim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scim>, <mailto:scim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Oct 2015 13:46:01 -0000

I’m looking for events that are the same as current SCIM to go over messaging, the security would be known and a callback wouldn’t be needed.  But the way you specify would work too, I hope something like this can be adopted soon.  Thanks, Chris

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Tuesday, October 13, 2015 4:16 PM
To: Chris Hyzer
Cc: scim@ietf.org
Subject: Re: [scim] scim over messaging

Chris,

Good question.

Yes. There has been some discussion. However it might not be quite the same use case.

Take a look at this:
https://tools.ietf.org/html/draft-hunt-scim-notify-00 (the draft has expired)

Some of us are still interested.  The current proposal is an asynchronous notification method to let one domain provider notify one or more subscribers of a changes they may be interested in. It could be tenancy to tenancy (domain wide), or it may be changes about a single resource to a subscribing mobile application.

When there are multiple domains, there are many cases where a change (e.g. a specific PATCH) might not work well in another domain - because each domain likely has a different set of information and thus slightly different information “state”.  Instead of pushing commands (as in the normal SCIM approach), the notify approach lets the receiver decide the correct action.  Eg.  Domain A provider notifies a mobile app of a change (Resource /Users/{id} had its name attribute change).  The subscriber calls back to the publishing domain provider and does a GET and decides what to do.  When the subscriber calls back, the subscribers right to see all of the information is then reviewed.

A couple of benefits:
* Makes differences in state between systems less problematic
* Allows normal SCIM access control to decide who should see what - this makes the definition of feeds and subscribers much simpler
* Dramatically reduces the information content (and privacy risk) in messages

The draft uses JWTs/JOSE to send notifications securely and makes it easy then to deliver via an alternate protocol.

Phil

@independentid
www.independentid.com<http://www.independentid.com>
phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>

On Oct 13, 2015, at 1:00 PM, Chris Hyzer <mchyzer@isc.upenn.edu<mailto:mchyzer@isc.upenn.edu>> wrote:

Has there been discussion about SCIM over messaging?

Ie. If sending SCIM through a messaging system (e.g. AWS SQS, activeMQ, etc)  where it is not HTTP.  Basically this means there is no response, and the request would need whatever would normally be in HTTP be in the message object.  E.g.


{

  "method": "PATCH",

  "resource": "/Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce"

  "body": {

    "schemas": ["urn:scim:schemas:core:1.0"],

    "members": [

      {

        "display": "Babs Jensen",

        "value": "pennperson:12345678",

        "operation": "delete"

      }

    ]

  }

}

Is something like this something that could be added to a future roadmap if not there already?

Thanks,
Chris

Ps. tried to send this earlier, sorry if this is a dupe
_______________________________________________
scim mailing list
scim@ietf.org<mailto:scim@ietf.org>
https://www.ietf.org/mailman/listinfo/scim