Subject: [scim] Questions about defined vs. supported schema

From: Phil Hunt <[email-masked]>
Date: Mon, 22 Sep 2014 10:42:56 -0700

I received a question from an implementer about how to indicate non-supported attributes that are defined in core-schema.

For example, a service provider doesn’t want to use “photos” as defined in the core schemas. 

Should it:

1.  Do nothing.  Just accept the values and then ignore them.

2.  In schemas, mark the attribute as “readOnly” and then ignore them. (this is acceptable in the current rules)

3.  Remove the attribute from Schemas.  If it then receives a value should it:
a. Ignore the value
b. Return a schema error.

In general, should we be silently ignoring attributes that are included in a JSON payload (e.g. on POST) that are not part of the schema?  Or, should the server throw an error?

With my editor hat off, my personal reaction is that servers should be flexible in what they accept and feel free to pick and choose data with appropriate DoS considerations. I have a tendency to think that a server can simply ignore data it does not understand or care about.  Further the server is free to alter any values it does accept as long as it returns the new values in its response.

That said, when we are talking about standard schema, it may be useful to do 2 above which tells a client admin why a server may not be appearing to accept an attribute value.  We may actually want to have a mutability of “unsupported” which simply means the server will ignore it entirely and will never return a value.  This is a bit better than “readOnly” which says the server may set the value but the client may not.

Phil

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

---

From: Leif Johansson <[email-masked]>
Date: Mon, 22 Sep 2014 19:56:47 +0200

On 2014-09-22 19:42, Phil Hunt wrote:
> I received a question from an implementer about how to indicate
> non-supported attributes that are defined in core-schema.
> 

speaking only as an individual...

> 2.  In schemas, mark the attribute as “readOnly” and then ignore them.
> (this is acceptable in the current rules)
> 

My gut feeling is 3b. If you aren't willing to store it, you shouldn't
pretend to.
	
	MVH leifj

---

From: "Alexis Bor" <[email-masked]>
Date: Mon, 22 Sep 2014 14:02:18 -0500

Seems to me that the simplest is to just drop bits that you don't want.
However, the reality of the situation could easily put you in a situation
where your are logging the events and a large amount of unprocessed data
gets stored in the event logs.  It's not a long distance to push those
events to Splunk and harvest the excess data.

I would tend to want to return a message back to the user so that this issue
is understood and hopefully adjusted.  It will lower the amount of data
coming in, processed, stored and logged.  

Alexis Bor

From: scim [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Monday, September 22, 2014 12:43 PM
To: SCIM WG
Subject: [scim] Questions about defined vs. supported schema

For example, a service provider doesn't want to use "photos" as defined in
the core schemas. 

Should it:

2.  In schemas, mark the attribute as "readOnly" and then ignore them. (this
is acceptable in the current rules)

3.  Remove the attribute from Schemas.  If it then receives a value should
it:

a. Ignore the value

In general, should we be silently ignoring attributes that are included in a
JSON payload (e.g. on POST) that are not part of the schema?  Or, should the
server throw an error?

With my editor hat off, my personal reaction is that servers should be
flexible in what they accept and feel free to pick and choose data with
appropriate DoS considerations. I have a tendency to think that a server can
simply ignore data it does not understand or care about.  Further the server
is free to alter any values it does accept as long as it returns the new
values in its response.

That said, when we are talking about standard schema, it may be useful to do
2 above which tells a client admin why a server may not be appearing to
accept an attribute value.  We may actually want to have a mutability of
"unsupported" which simply means the server will ignore it entirely and will
never return a value.  This is a bit better than "readOnly" which says the
server may set the value but the client may not.

Phil

@independentid

www.independentid.com <http://www.independentid.com> 

[email-masked] <mailto:[email-masked]>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 22 Sep 2014 12:28:45 -0700

We’ve had principles elsewhere that the server is free to ignore undefined parameters (e.g. in the API requests such as retrieval).

For payload, should service providers be consistent and ignore data that is not understood/defined?  Or should they be strict?

Where this appears to break down, is that a SCIM client that sends payload that is conformant to the spec could get penalized because the server does not conform to the spec (it doesn’t support all attributes defined in the spec).  In this case, if we follow your thought, then it is more important that clients conform to individual servers rather than the specification.  This leads us to having to write more deployment specific connectors because each connector must conform to the deployment more than the spec.

In general how should we draw the line on the REST principle of being flexible in what is accepted?

3 possible options:

1.  Strict - server specific: Clients must conform to the schema published by individual servers.
2.  Server Specific + Standard Schema: Clients can look at server schema for extensions, but may use any published schema (the server does not have to accept the values and will not throw errors).  Clients MAY not add attributes if they are not defined in the server schema or published in core schema.
3.  Loose: Clients can choose to add any attributes they want but the server is free to ignore. Service providers should be careful not to log requests in detail and must consider DoS ramifications.

As an individual I think #2 strikes the right balance.  Further I would not force servers to throw an error (maybe it is a SHOULD?)

Phil

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

On Sep 22, 2014, at 12:02 PM, Alexis Bor <[email-masked]> wrote:

> Seems to me that the simplest is to just drop bits that you don’t want.  However, the reality of the situation could easily put you in a situation where your are logging the events and a large amount of unprocessed data gets stored in the event logs.  It’s not a long distance to push those events to Splunk and harvest the excess data.
>  
> I would tend to want to return a message back to the user so that this issue is understood and hopefully adjusted.  It will lower the amount of data coming in, processed, stored and logged. 
>  
> Alexis Bor
>

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 22 Sep 2014 19:58:33 +0000

I have a tendency to agree for items in core schema 

-----Original Message-----
From: scim [mailto:[email-masked]] On Behalf Of Leif Johansson
Sent: Monday, September 22, 2014 10:57 AM
To: [email-masked]
Subject: Re: [scim] Questions about defined vs. supported schema

On 2014-09-22 19:42, Phil Hunt wrote:
> For example, a service provider doesn't want to use "photos" as 
> defined in the core schemas.
> 

> 2.  In schemas, mark the attribute as "readOnly" and then ignore them.

My gut feeling is 3b. If you aren't willing to store it, you shouldn't pretend to.
	
	MVH leifj

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

---

From: Grahame Grieve <[email-masked]>
Date: Tue, 23 Sep 2014 06:05:03 +1000

in which case either the error has to computably tied to a particular
element, or the schema has to be able to indicate what is not
supported. Since the schema allows design or deployment time decision
making it would much superior

Grahame

-- 
-----
http://www.healthintersections.com.au /
[email-masked] / +61 411 867 065

---

From: Ian Glazer <[email-masked]>
Date: Mon, 22 Sep 2014 14:20:12 -0700

On Mon, Sep 22, 2014 at 10:42 AM, Phil Hunt <[email-masked]> wrote:

> In general, should we be silently ignoring attributes that are included in
> a JSON payload (e.g. on POST) that are not part of the schema?  Or, should
> the server throw an error?
>
> appropriate DoS considerations. I have a tendency to think that a server
> can simply ignore data it does not understand or care about.  Further the
> server is free to alter any values it does accept as long as it returns the
> new values in its response.
>
> That said, when we are talking about standard schema, it may be useful to
> do 2 above which tells a client admin why a server may not be appearing to
> “unsupported” which simply means the server will ignore it entirely and
> will never return a value.  This is a bit better than “readOnly” which says
> the server may set the value but the client may not.
>
> Doing 2 seems like a workable hack but a hack nonetheless. I like the idea
of an "unsupported" mutability - makes things a bit more clear

-- 
Ian Glazer
Senior Director, Identity
+1 202 255 3166
@iglazer <https://twitter.com/iglazer>

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Mon, 22 Sep 2014 22:18:58 +0000

Speaking as an implementer: our current implementation is doing 3B.  2 is certainly an option, but I like the idea of unsupported mutability the best. The question is what is the semantics if a server defines “photos” as unsupported, but gets a put request with it?  Does it ignore the value or return a schema error?  I see pro/cons for both.

Cheers,
Morteza

From: Ian Glazer <[email-masked]<mailto:[email-masked]>>
Date: Monday, September 22, 2014 at 2:20 PM
To: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scim] Questions about defined vs. supported schema

On Mon, Sep 22, 2014 at 10:42 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
I received a question from an implementer about how to indicate non-supported attributes that are defined in core-schema.

Should it:

Doing 2 seems like a workable hack but a hack nonetheless. I like the idea of an "unsupported" mutability - makes things a bit more clear

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

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

--
Ian Glazer
Senior Director, Identity
+1 202 255 3166
@iglazer<https://twitter.com/iglazer>

---

From: Thomas Krille <[email-masked]>
Date: Tue, 23 Sep 2014 10:41:48 +0200

Hello,

I think a SCIM server should obey Postel's law, i.e. *Be conservative in
what you do, be liberal in what you accept from others *[1]. So just
ignoring attributes that are not supported should be totally fine. In fact,
as a SCIM server always returns the changed resource, one can always figure
out if some attribute was actually saved or not. The idea to define a
special value "unsupported" for the "mutability" attribute sounds good. At
least this way clients can figure out, too, why their attribute was not
stored by the server. On the other hand, just removing the attribute from
schemas has the same effect: you sending the unsupported attribute "photos"
to the server, it ignores it, and you can query the server what attributes
it support, seeing that it does not list "photos".

So, I think 3.a is the best option, but adding a special value
"unsupported" for the "mutability" attribute might also be a good thing.

[1] http://en.wikipedia.org/wiki/Robustness_principle

-- 
Thomas Krille
Softwareentwicklung
tarent solutions GmbH

Telefon +49 (0) 30 138803-128
Telefax +49 (0) 228 54881-235
[email-masked]

Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-0 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander
Steeg

2014-09-23 0:18 GMT+02:00 Morteza Ansari (moransar) <[email-masked]>:

>  Speaking as an implementer: our current implementation is doing 3B.  2
> is certainly an option, but I like the idea of unsupported mutability the
> best. The question is what is the semantics if a server defines “photos” as
> unsupported, but gets a put request with it?  Does it ignore the value or
> return a schema error?  I see pro/cons for both.
>
>
>  Cheers,
> Morteza
>
>   From: Ian Glazer <[email-masked]>
> To: Phil Hunt <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
>>  In general, should we be silently ignoring attributes that are included
>> in a JSON payload (e.g. on POST) that are not part of the schema?  Or,
>> should the server throw an error?
>>
>>  That said, when we are talking about standard schema, it may be useful
>> to do 2 above which tells a client admin why a server may not be appearing
>> to accept an attribute value.  We may actually want to have a mutability of
>>   Doing 2 seems like a workable hack but a hack nonetheless. I like the
> idea of an "unsupported" mutability - makes things a bit more clear
>
>
>>        Phil
>>
>>  @independentid
>> www.independentid.com
>>  [email-masked]
>>
>>
>>
>>