Subject: [scim] Proposed changes for attribute schema

From: Phil Hunt <[email-masked]>
Date: Wed, 2 Oct 2013 17:07:52 -0700

Tickets 10 (attribute sensitivity), 35 (mutability), and 47 (indexing) all specify qualities that attributes may have in a SCIM service provider.  The following is proposed changes to section 3.

Original text

>    A resource is a collection of attributes identified by one or more
>    schemas.  Minimally, an attribute consists of the attribute name and
>    at least one Simple or Complex value either of which may be Multi-
>    valued.  SCIM schema defines the data type, plurality and other
>    distinguishing features of an attribute.  Unless otherwise specified
>    all attributes are modifiable by Consumers.  Immutable (read-only)
>    attributes SHALL be specified as 'READ-ONLY' within the attribute
>    definition.  Additionally, Service Providers MAY choose to make some
>    or all Resource attributes immutable and SHOULD identify those
>    attributes via the associated Resource's schema endpoint
>    (Section 5.2).

Proposed text:
A resource is a collection of attributes identified by one or more schemas. 
Minimally, an attribute consists of the attribute name and at least one 
Simple or Complex value either of which may be Multi-valued.  

<New Section> Attribute Meta-Data Schema

SCIM schema 
defines the data type, plurality and other distinguishing features of an 
attribute.  

multiValued	is a BOOLEAN that expresses whether the attribute MAY have multiple values.

mutability	is a keyword that MAY be ONE of the following values: 
	"readWrite"  means that the attribute MAY be returned or updated.
        "readOnly"   means that the attribute MAY be returned in response to a SCIM request. A readOnly attribute MAY be used in a SCIM GET request. A readOnly attribute MAY NOT be used in the request portion of a POST, PUT, or PATCH operation.
	"writeOnly"  means that an attribute MAY NOT be returned in any response to a SCIM request. The attribute MAY be included in a POST, PUT, or PATCH request. The attribute MAY NOT be used in a GET request.
	"immutable"  means that an attribute MAY only be set once at record creation during a POST or PUT operation. [[should we allow PUT on a replace operation?]]

returned	is a keyword that indicates when attribute values are returned on a query or SCIM response. The keyword MAY be ONE of the following values: 
 	"always"     is used for attributes that must always be returned such as "id"
 	"never"      is used for write-only attributes or other internal data. 
	"default"    means the specified attribute is returned when the attribute parameter of a GET query is omitted. 
	"request"    means that the attribute will only be returned if requested.

index		is a keyword that indicates what type of search filter MAY be used with the attribute. Note that if the server does not support unindexed searches, specifying a filter type not supported by the index returns a no match for the purposes of filter processing. The index MAY be one or more of the following:
	"substring"  the specified filter string MUST be contained within the attribute value.
	"startsWith" the specified filter string MUST occur at the start of the attribute value.
	"endsWith"   the specified filter string MUST occur at the end of the attribute value.
        "exact"	     the specified filter string MUST exactly match the attribute value.

In section 12.7, the schema representation for all attributes needs to be updated to reflect the new attribute meta values.  Note "readOnly" is replaced by "mutability".

Since individual servers can choose their own values for mutability, index, multiValued, etc, the JSON structure would have to be non-normative.

Phil

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

---

From: Samuel Erdtman <[email-masked]>
Date: Sun, 6 Oct 2013 18:54:42 -0500

Hi
Good write up, some minor comments/thoughts:

"The attribute MAY NOT be used in a GET request"

does this men that you are not allowed to filter of write only
attributes or does it mean that the service provider is not allowed to
return the value. If it is the second I think this sentence is
unclear.

"should we allow PUT on a replace operation?"

If we need immutable then I do not think PUT should change immutable
values. What is the use-case for immutable? is group immutable or
readonly? and what is the relation between immutable and readonly.

"is used for attributes that must always be returned such as "id""

Could we add something about that it is not possible for the client to
exclude these attributes.

Do we really need all the keywords for "returned":

I think that write only indicates that an attribute is not
possible/allowed to be returned. Then I think that hawing both default
and requested created abundant information. Could we not just have
"default" and explain in text that attributes that are not "always" or
"default" are only returned if requested.

I still do not rely see that "index" is needed but if the group feels
that it is I think that we need to specify here how do we specify
several now it only says "The index MAY be one or more of the
following" Is it a comma separated list or a json-array?

Cheers

//Samuel

On Wed, Oct 2, 2013 at 7:07 PM, Phil Hunt <[email-masked]> wrote:

> Tickets 10 (attribute sensitivity), 35 (mutability), and 47 (indexing) all
> specify qualities that attributes may have in a SCIM service provider.  The
> following is proposed changes to section 3.
>
> Original text
>
>    attributes SHALL be specified as 'READ-ONLY' within the attribute   definition.  Additionally, Service Providers MAY choose to make some
>
>    (Section 5.2 <http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-5.2>).
>
>
>
> Proposed text:
>
> In section 12.7, the schema representation for all attributes needs to be
> updated to reflect the new attribute meta values.  Note "readOnly" is
> replaced by "mutability".
>
> Since individual servers can choose their own values for mutability,
> index, multiValued, etc, the JSON structure would have to be non-normative.
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
>
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim
>
>