Re: [scim] Common attributes repeated in schemas

["Morteza Ansari (moransar)" <[e-mail]>]

Speaking as an implementor, given the small number of  resource types and small number of common attributes, I rather keep it simple and duplicate the definition.  Purely from readability/simplicity point of view.  Also I don’t think we can assume all extension types will have the same common attributes.

I do agree we should better define “meta” though.


Cheers,
Morteza

From: Phil Hunt <[e-mail]<mailto:[e-mail]>>
Date: Monday, September 8, 2014 at 1:15 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [scim] Common attributes repeated in schemas

One other issue I noticed.  While “id” and “externalId” are defined as part of User and Group, the “meta” attribute is not defined.

I propose that as part of creating this special “Common” schema, we include the complex attribute “meta” in that definition.

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[e-mail]<mailto:[e-mail]>



On Sep 8, 2014, at 12:52 PM, Phil Hunt <[e-mail]<mailto:[e-mail]>> wrote:

First, some background: I am working on a new revision of the core-schema draft document that will also clean up some terminology (e.g. confusing use of ‘core’: core-schema, vs core-attributes, vs. core-resource etc) and better explain how resourceTypes are established and defined. So far, the changes have been clarifying only, but I ran into this item which suggests we may want to make some subtle changes.

Reviewing the Schema section of the core-schema draft, I see that the common attributes like id and externalId are repeated in each schema. For example in the definition for Group, we have…

  {
    "id" : "urn:ietf:params:scim:schemas:core:2.0:Group",
    "name" : "Group",
    "description" : "Group",
    "attributes" : [
      {
        "name" : "id",
        "type" : "string",
        "multiValued" : false,
        "description" : "Unique identifier for the SCIM resource as defined by the Service Provider. Each representation of the resource MUST include a non-empty id value. This identifier MUST be unique across the Service Provider's entire set of resources. It MUST be a stable, non-reassignable identifier that does not change when the same resource is returned in subsequent requests. The value of the id attribute is always issued by the Service Provider and MUST never be specified by the Service Consumer. REQUIRED.",
        "required" : true,
        "caseExact" : false,
        "mutability" : "readWrite",
        "returned" : "always",
        "uniqueness" : "server"
      },
      {
        "name" : "externalId",
        "type" : "string",
        "multiValued" : true,
        "description" : "An identifier for the Resource as defined by the Service Consumer.",
        "required" : false,
        "caseExact" : false,
        "mutability" : "readWrite",
        "returned" : "default",
        "uniqueness" : "none"
      },

…. and so on into the group specific attrs

If you look at the other schemas like the one for User, you will see these same attributes repeated.

Because of this, I am worried about the possibility that there may be conflicting definitions of attribute characteristics between schemas.  E.g. externalId is multi-valued in one, but not another. This could lead to configuration conflicts between schemas.

I’m wondering if we should create a new schema called “Common” which is a mandatory schema to any object schema. Its URI does not need to be included in the schemas attribute, but is always assumed present.

urn:ietf:params:scim:schemas:core:2.0:Common

As well, while this schema looks like an extension, all of its attributes belong at the “top” level json structure within the resource rather than in an extension URI based grouping (e.g. as we do with enterprise User extension attributes).

Maybe since there are only a couple of common attributes I am overstating the problem and this won’t be an issue in practice.

Is there a better way to express this?

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[e-mail]<mailto:[e-mail]>



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