Subject: Re: [scim] Common Attribute "schemas" Characteristics

From: Shelley <[email-masked]>
Date: Fri, 11 Sep 2020 10:13:48 -0500

Regarding the "*returned*" characteristic for the "*schemas*" attribute...
RFC 7644 includes examples with conflicting behavior for the "schemas"
returned characteristic.

In section 3.4.2 [1], the example query which specifies "attributes" does *not
*return the "schemas" by default:

GET /Users*?attributes=userName*
{
 "schemas":["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
 "totalResults":2,
 "Resources":[

*   {     "id":"2819c223-7f76-453a-919d-413861904646",
 "userName":"bjensen"   },   {
 "id":"c75ad752-64ae-4823-840d-ffa80929976c",     "userName":"jsmith"   }*
 ]
}

However, in section 3.9 [2], "schemas" *is *returned by default in the
response, despite the "attributes" parameter not specifying this attribute:

GET /Users/2819c223-7f76-453a-919d-413861904646*?attributes=userName*
{
 "schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],

* "id":"2819c223-7f76-453a-919d-413861904646",* "userName":"bjensen"
}

RFC 7643 generally indicates throughout that "schemas" MUST be specified;
however, it is not clear as to whether the requirement is referring to
requests and/or responses. Unlike the "id" attribute, which clearly
specifies that it is expected to have a returned characteristic of
"always", the other common attributes don't clearly specify this
characteristic. Is "default" the correct attribute, such that the example
in RFC 7644 Section 3.9 is not correct?

[1] https://tools.ietf.org/html/rfc7644#section-3.4.2
[2] https://tools.ietf.org/html/rfc7644#section-3.9

On Fri, Mar 13, 2020 at 12:10 PM Phillip Hunt <[email-masked]>
wrote:

> Shelley
>
> In practical/pragmatic terms...case insensitive.
>
> I treat as case insensitive since it is unlikely and unwise if two
> separate schemas only differentiated by case.
>
> I would also expect iana process to reject “overlapping” registrations
> differentiated only by case.
>
> Phil
>
> On Mar 13, 2020, at 9:16 AM, Shelley <[email-masked]> wrote:
>
> 
> What are the characteristics for the "schemas" [1] attribute?
>
> Here is my attempt at defining these characteristics using the Schema
> definitions:
>
>    - "type" is "reference"
>    - "referenceTypes" is ["uri"]
>    - "required" is "true"
>    - "multiValued" is "true"
>    - "uniqueness" is "none"
>    - "caseExact" as "true" (since this is a "reference" type)
>    - "mutability" of "immutable" (although none of the mutability values
>    seems like a perfect fit)
>    - "returned" characteristic of "default"
>
> Although "schemas" and the "Common Attributes" don't define their own
> schemas, it would be nice to have all of these attributes' characteristics
> clearly defined in the spec using the Schema definition to help provide a
> clear/common definition, particularly, since these characteristics are not
> intended to be modified/defined by SPs..
>
> In particular, in my SCIM implementation, I have been considering whether
> to evaluate "schemas" in resource representations* case-sensitively*
> (exact case as defined in the ResourceType),* case-insensitively* (any
> case allowed), or using *lexical equivalence* (e.g. for URNs,
> case-insensitive schema and NID, case-sensitive NSS, and some components
> ignored). The RFC doesn't seem to clearly prescribe this, but based on the
> fact that the implied type is "reference" which (debatably [2]) has
> "caseExact" as "true" and the fact that the attribute "MUST only contain
> values defined as "schema" and "schemaExtensions"", I'm under the
> assumption that this attribute is *case-sensitive*.
>
> Please confirm. Thanks!
>
> [1] https://tools.ietf.org/html/rfc7643#section-3
> [2]
> https://mailarchive.ietf.org/arch/msg/scim/05_K_y-V26EOfN2F7fuSO3DXoLw/
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim
>
>

---

From: Phillip Hunt <[email-masked]>
Date: Fri, 11 Sep 2020 17:26:22 -0700

AFAIK, Schemas has to always be returned so that parsers know the claims/contents of the json object.

I’d have to check but I think all common attributes are returned (eg schemas, id, meta).  

Phil

> On Sep 11, 2020, at 8:13 AM, Shelley <[email-masked]> wrote:
> 
> 
> Regarding the "returned" characteristic for the "schemas" attribute... RFC 7644 includes examples with conflicting behavior for the "schemas" returned characteristic.
> 
> In section 3.4.2 [1], the example query which specifies "attributes" does not return the "schemas" by default:
> 
> GET /Users?attributes=userName
> {
>      "id":"2819c223-7f76-453a-919d-413861904646",
>      "userName":"bjensen"
>    },
>    {
>      "id":"c75ad752-64ae-4823-840d-ffa80929976c",
>      "userName":"jsmith"
>    }
>  ]
> }
> 
> However, in section 3.9 [2], "schemas" is returned by default in the response, despite the "attributes" parameter not specifying this attribute:
> 
> GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=userName
> {
>  "id":"2819c223-7f76-453a-919d-413861904646",
>  "userName":"bjensen"
> }
> 
> RFC 7643 generally indicates throughout that "schemas" MUST be specified; however, it is not clear as to whether the requirement is referring to requests and/or responses. Unlike the "id" attribute, which clearly specifies that it is expected to have a returned characteristic of "always", the other common attributes don't clearly specify this characteristic. Is "default" the correct attribute, such that the example in RFC 7644 Section 3.9 is not correct?
> 
>> On Fri, Mar 13, 2020 at 12:10 PM Phillip Hunt <[email-masked]> wrote:
>> Shelley
>> 
>> I treat as case insensitive since it is unlikely and unwise if two separate schemas only differentiated by case. 
>> 
>> I would also expect iana process to reject “overlapping” registrations differentiated only by case. 
>> 
>> Phil
>> 
>>> Here is my attempt at defining these characteristics using the Schema definitions:
>>> "type" is "reference"
>>> "referenceTypes" is ["uri"]
>>> "required" is "true"
>>> "multiValued" is "true"
>>> "uniqueness" is "none"
>>> "caseExact" as "true" (since this is a "reference" type)
>>> "mutability" of "immutable" (although none of the mutability values seems like a perfect fit)
>>> "returned" characteristic of "default"
>>> Although "schemas" and the "Common Attributes" don't define their own schemas, it would be nice to have all of these attributes' characteristics clearly defined in the spec using the Schema definition to help provide a clear/common definition, particularly, since these characteristics are not intended to be modified/defined by SPs..
>>> 
>>> In particular, in my SCIM implementation, I have been considering whether to evaluate "schemas" in resource representations case-sensitively (exact case as defined in the ResourceType), case-insensitively (any case allowed), or using lexical equivalence (e.g. for URNs, case-insensitive schema and NID, case-sensitive NSS, and some components ignored). The RFC doesn't seem to clearly prescribe this, but based on the fact that the implied type is "reference" which (debatably [2]) has "caseExact" as "true" and the fact that the attribute "MUST only contain values defined as "schema" and "schemaExtensions"", I'm under the assumption that this attribute is case-sensitive.
>>> 
>>> Please confirm. Thanks!
>>> 
>>> [2] https://mailarchive.ietf.org/arch/msg/scim/05_K_y-V26EOfN2F7fuSO3DXoLw/

---

From: Shelley <[email-masked]>
Date: Fri, 11 Sep 2020 20:10:27 -0500

If callers are specifying their requested attributes, then they can either
request "schemas" or they should already know the type of resource being
requested.

>From RFC 7643:

   - Section 2.2 indicates that the default "returned" characteristic is
   "default" unless otherwise specified in Section 7 [1]
   - Section 7 indicates that all attributes, other than "id", have a
   default characteristic of "default" [2]
   - "meta" explicitly indicates that it has a "returned" characteristic of
   "default" [3]
   - "id" explicitly indicates that it has a "returned" characteristic of
   "always" [4]
   - "password" explicitly indicates that it has a "returned"
   characteristic of "never" [5]

Aside from the above, I see no mention of any other attributes having
anything other than "default" returned characteristic.Given this, my
presumption would be that "schemas" should be "default," even though it's
not explicitly stated?

[1] https://tools.ietf.org/html/rfc7643#section-2.2
[2] https://tools.ietf.org/html/rfc7643#section-7
[3] https://tools.ietf.org/html/rfc7643#page-17
[4] https://tools.ietf.org/html/rfc7643#section-3.1
[5] https://tools.ietf.org/html/rfc7643#page-22

On Fri, Sep 11, 2020 at 7:26 PM Phillip Hunt <[email-masked]>
wrote:

> Regarding the "*returned*" characteristic for the "*schemas*"
> attribute... RFC 7644 includes examples with conflicting behavior for the
> "schemas" returned characteristic.
>