Subject: Re: [scim] #10: Add ability to mark attributes as sensitive in the schemas

From: Phil Hunt <[email-masked]>
Date: Wed, 30 Oct 2013 12:03:24 -0700

Chris

I am not sure how visibility is related to policy. This is strictly a protocol issue.

You still need to define policy on top that says who may see what etc. but this doesn't impact when the protocol has indicated or not that an attribute is requested for return.  

Phil

> On Oct 30, 2013, at 11:42, scim issue tracker <[email-masked]> wrote:
> 
> #10: Add ability to mark attributes as sensitive in the schemas
> 
> 
> Comment (by [email-masked]):
> 
> Replying to [comment:5 phil.hunt@…]:
>> In order to bring Ticket 10 (
> http://trac.tools.ietf.org/wg/scim/trac/ticket/10 ) to a close, the
> following is a new schema attribute (Section 11) definition which defines
> when an attribute is returned on a query. It defines 4 modes.
>> {{{
>> returned - A value that indicates when an attribute's value is returned
> in a SCIM GET
>> operation or in response to a PUT, POST, or PATCH request. Valid values
> are:
>> * always - The attribute is always returned regardless of the contents
> of the "attributes" parameter [API Sec 3.2.3]. For example, "id" is always
> returned to identify the SCIM record.
>> * never - The attribute is never returned. This is typically used in
> RESTful operations where the attribute supports only update operations. An
> attribute with "returned" set to "never" MAY be used in a search filter
> [[depending on index support]].
>> * default - The attribute is returned in SCIM responses and is returned
> when the GET "attributes" parameter [API Sec 3.2.3] is not specified.
>> * request - The attribute is returned in response to any SCIM PUT,
> POST, or PATCH operations if the attribute was specified by the client
> (for example, the attribute was modified). The attribute is returned in a
> SCIM GET operation only if specified in the "attributes" parameter [API
> Sec 3.2.3].
>> }}}
>> 
>> Please let me know if you agree, or if you have concerns.
>> 
>> Note we may need more discussion on the default "returned" values for
> some attributes.  For now, I'll consult with Kelly and put together a set
> of proposed defaults (e.g. "id" is "always").
> 
> Hi Phil & community.
> 
> Please see comment in ticket #11 regarding SCIM and how it captures (or
> doesn't) security policies:
> 
> "I would propose to the SCIM community that if this model proceeds that
> there is agreement to the principle that SCIM does not embody policy nor
> enforce it beyond what is in the specification today. These elements are
> layered on top of SCIM."
> 
> I think that the elephant in the room around a few of these tickets
> (current state of 10, ticket #11) is a contemplation and recommendation of
> what style of policies we want to recognize SCIM as the protocol to
> implement policy to content it transits.
> 
> To seed the topic further:
> 
> As I see it, SCIM currently relies on endpoints for security and the
> policy enforcement.  SCIM doesn't have a lot of instrumentation to do much
> around putting into effect any of the security mechanisms or policies on
> it's own and does not police compliance(e.g. little to none in referential
> integrity and  no enforcement of rules either e.g. 'if this attribute A
> has value X, attribute B MUST not have value Z'). The offshoot is that
> it's all about attributes and the content, not the control infrastructure.
> That's up to the endpoints to capture and enforce and if a response
> violates it throw an appropriate error message to trigger the re-
> evaluation of the request.
> 
> If we don't abstract things out in this fashion what will happen is we are
> going to get a Frankenstein control infrastructure that is a hodge podge
> of practices but not standards (is there a standard for group management?
> is there a standard for role based access control?) which will reflect
> what we know of today but not be 'evergreen' for times to come.  It will
> also be contradictory to one audience at the expense of another.
> For instance, if I'm an organization that adopts the pattern of group
> based access control but engage a SCIM endpoint that is entitlement based,
> how will I ever get data from point A to point B without hammering
> something into the data and transcoding one model to another??
> How will I ever know that my patterns on policy and security hold true?
> In a model where it's at the endpoint, I can evaluate it there without
> worry of some in transit data may skew my evaluation.
> 
> I would like to engage the community on the track that the act of
> codifying policy should be done on top of SCIM and SCIM be preserved as a
> method to transit the data unfiltered.
> 
> If the community thinks otherwise (as this post is below) then I would
> like to understand the rational more deeply than is expressed today which
> would include why it couldn't be done at the edge and what's the value
> proposition to embed it in SCIM.  There are existing protocols (LDAP being
> one) that have richly defined concepts so why should we not either adopt a
> pre-existing model instead of creating yet another one?
> 
> -- 
> -------------------------------------+-----------------------------------
> Reporter:  [email-masked]  |       Owner:  [email-masked]
>     Type:  enhancement              |      Status:  new
> Priority:  major                    |   Milestone:
> Component:  core-schema              |     Version:
> Severity:  -                        |  Resolution:
> Keywords:                           |
> -------------------------------------+-----------------------------------
> 
> Ticket URL: <http://trac.tools.ietf.org/wg/scim/trac/ticket/10#comment:6>
> scim <http://tools.ietf.org/scim/>
>

---

From: Chris Phillips <[email-masked]>
Date: Wed, 30 Oct 2013 15:11:04 -0400

Maybe I'm not understanding it well enough.

Who or what actor in the SCIM model consumes and acts on the 'always,
never, default, request'  modes ?

Is it appropriate for me to presume it's the implementation of the SCIM
endpoint then?

Chris.

On 13-10-30 3:03 PM, "Phil Hunt" <[email-masked]> wrote:

>You still need to define policy on top that says who may see what etc.
>but this doesn't impact when the protocol has indicated or not that an
>attribute is requested for return.
>
>Phil
>
>> Replying to [comment:5 phil.hunt@Š]:
>> Ticket URL: 
>><http://trac.tools.ietf.org/wg/scim/trac/ticket/10#comment:6>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 30 Oct 2013 12:29:45 -0700

Chris,

All this does is make clear how the attributes parameter is interpreted by the server.

This has nothing to do with whether the client has the right to read or update anything.

If you want to have a very simplistic implementation, you could make all attributes returned by "default". 

However you will immediately run into issues like:

1.  If a client requests attribute mail for all records that match a filter, how does the client know what record it came from if multiple records are returned.  This brings up the first case that "id" MUST always be returned.

2.  Some values are hashed and thus cannot be returned. They are effectively write only.  Doesn't matter what policy is, they cannot be read (well you could return the hash if you really want to).  So this brings up the case "never".

3.  "default" and "request" are intended for differentiating between what is "typical" attributes that clients will want, and SP schema, or operational data clients aren't normally interested in.   So for example, in many cases clients might not want things like created timestamps, etc.  These attributes can be made "request" only meaning they are only returned if requested.

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-10-30, at 12:11 PM, Chris Phillips <[email-masked]> wrote:

> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim