Subject: [scim] Normative Schema Representation Example

From: Shelley <[email-masked]>
Date: Mon, 4 Feb 2013 11:16:32 -0600

The JSON schema representation in "11.6. Resource Schema Representation"
doesn't appear to be "normative" as indicated, since it merely provides an
example Schema resource for a User. Should this be updated to a
"non-normative example" instead?

---

From: Kelly Grizzle <[email-masked]>
Date: Mon, 4 Feb 2013 20:08:02 +0000

You're right, Shelley.  I opened issue 34 to get this fixed.

http://trac.tools.ietf.org/wg/scim/trac/ticket/34

--Kelly

From: [email-masked] [mailto:[email-masked]] On Behalf Of Shelley
Sent: Monday, February 04, 2013 11:17 AM
To: [email-masked]
Subject: [scim] Normative Schema Representation Example

The JSON schema representation in "11.6. Resource Schema Representation" doesn't appear to be "normative" as indicated, since it merely provides an example Schema resource for a User. Should this be updated to a "non-normative example" instead?

---

From: Shelley <[email-masked]>
Date: Mon, 4 Feb 2013 18:17:21 -0600

Thanks, Kelly.

Reviewing this example also prompted a few additional questions that
weren't clear to me in the spec -

* [Core Schema Attributes] Must service providers expose *all *attributes
for User/Group as defined in the core schema? Or, is it acceptable for
service providers to only declare/accept a subset of these attributes?

* [Extension Schema Attributes] Similar to the previous question, must
service providers expose all attributes from schema extensions?
Specifically, in the example in 11.6, it looks like only one of the
enterprise extension attributes is specified.

* [Additional Attributes] Does SCIM prescribe or recommend an approach for
handling unknown attributes provided by consumers (i.e. those that are not
listed in the Resource Schema)? Given the schema-based nature of resources
and the fact that providers may ignore POSTed content (per the SCIM
Protocol 3.1), it seems that unknown attributes should likely be ignored
(such that they are not persisted/returned nor is an error returned).

On Mon, Feb 4, 2013 at 2:08 PM, Kelly Grizzle
<[email-masked]>wrote:

>  You’re right, Shelley.  I opened issue 34 to get this fixed.****
>
> ** **
>
> http://trac.tools.ietf.org/wg/scim/trac/ticket/34****
>
> ** **
>
> --Kelly****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Shelley
> *Sent:* Monday, February 04, 2013 11:17 AM
> *To:* [email-masked]
> *Subject:* [scim] Normative Schema Representation Example****
>
> ** **
>
> "non-normative example" instead?****
>

---

From: Kelly Grizzle <[email-masked]>
Date: Tue, 5 Feb 2013 14:39:24 +0000

> [Core Schema Attributes] Must service providers expose all attributes for User/Group as defined in the core schema?

No.  Service providers may just declare/accept a subset.

> [Extension Schema Attributes] Similar to the previous question, must service providers expose all attributes from schema
> extensions? Specifically, in the example in 11.6, it looks like only one of the enterprise extension attributes is specified.

No.  Service providers can just expose a subset.  I believe that since 11.6 is non-normative (as you pointed out), this is just
showing an example of what the schema resource might look like.

>  it seems that unknown attributes should likely be ignored (such that they are not persisted/returned nor is an error returned).

I believe this is correct.

--Kelly

From: Shelley [mailto:[email-masked]]
Sent: Monday, February 04, 2013 6:17 PM
To: Kelly Grizzle
Cc: [email-masked]
Subject: Re: [scim] Normative Schema Representation Example

Thanks, Kelly.

Reviewing this example also prompted a few additional questions that weren't clear to me in the spec -

* [Core Schema Attributes] Must service providers expose all attributes for User/Group as defined in the core schema? Or, is it acceptable for service providers to only declare/accept a subset of these attributes?

* [Extension Schema Attributes] Similar to the previous question, must service providers expose all attributes from schema extensions? Specifically, in the example in 11.6, it looks like only one of the enterprise extension attributes is specified.

* [Additional Attributes] Does SCIM prescribe or recommend an approach for handling unknown attributes provided by consumers (i.e. those that are not listed in the Resource Schema)? Given the schema-based nature of resources and the fact that providers may ignore POSTed content (per the SCIM Protocol 3.1), it seems that unknown attributes should likely be ignored (such that they are not persisted/returned nor is an error returned).

On Mon, Feb 4, 2013 at 2:08 PM, Kelly Grizzle <[email-masked]<mailto:[email-masked]>> wrote:
You're right, Shelley.  I opened issue 34 to get this fixed.

--Kelly

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Shelley
Sent: Monday, February 04, 2013 11:17 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [scim] Normative Schema Representation Example

---

From: Chris Phillips <[email-masked]>
Date: Tue, 5 Feb 2013 09:42:28 -0500

Shelly,

Good questions around attribute visibility.
 From my perspective, in order to answer the questions you pose we would have to talk about the security model overlaid on SCIM. This topic has been deferred somewhat by relegating security policy to be handled by the security context of the endpoint.  If you can connect, then you can transact.  You can see the TBD's in the draft docs as indicators that these are areas that have not been fully explored.

As a dialog starter:

The spirit of simplicity drives the security policy to the context of the endpoint and not internalized in the SCIM protocol, or as minimally as possible. The artifact of this is that by virtue of connecting I am able to see 'everything' and therefore the answers to the questions below would :

Must service providers expose all attributes?  YES
For extensions as well? YES

The follow on question on the tip of the tongue is: Should this concerning?  Maybe, maybe not.

To help understand the concerns I think that a discussion around what is needed, if anything,  beyond endpoint security contexts would be useful to describe the position SCIM as a protocol has regarding security.

I'm sure some folks are prepared to freak out about this, but I haven't heard people complain greatly about the 1.0 implementations about security or any changes for 2.0.  It may be that the endpoint security context is 'just enough' and saying that once in the front door you are free to roam around in the protocol is more valuable than a more complex protocol that is encumbered with a heavy model (read: anything more than the endpoint context).
As a follow on point to this, the implicit context of SCIM is that it is intentionally a conduit for identity information and has Personally Identifiable Information (PII) throughout.  This is why transactions should be over SSL and  the confidence of the veracity of  whom is connecting should be important to you.  These are not new concerns limited to SCIM and are endpoint driven from my perspective.

If you want more contexts today, there's nothing preventing a site to stand up multiple SCIM endpoints each with a  different security policy context either.   It would be up to the implementer to tailor the endpoint to the kind of context they want to present.

This isn't to say security is 'solved' though, I think discussion around how to use SCIM within different contexts and what implications it has on the protocol are good to explore.  Some of the key questions that come to mind are:

 *   where in the SCIM model could the responsibility be BESIDES or in conjunction with the endpoint?
 *   what KIND of model would it be?
 *   How could it be applied and in conjunction with endpoint security?
 *   How does it apply to extensions without encumbering the ability to extend unnecessarily?
 *   How would it scale to arbitrarily large number of endpoints?
 *   How would SCIM transactions be  encapsulated within other protocols that take care of security like SAML?

Chris.

From: Shelley <[email-masked]<mailto:[email-masked]>>
Date: Monday, 4 February, 2013 7:17 PM
To: Kelly Grizzle <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scim] Normative Schema Representation Example

Thanks, Kelly.

On Mon, Feb 4, 2013 at 2:08 PM, Kelly Grizzle <[email-masked]<mailto:[email-masked]>> wrote:
You’re right, Shelley.  I opened issue 34 to get this fixed.

--Kelly

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Shelley
Sent: Monday, February 04, 2013 11:17 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [scim] Normative Schema Representation Example

---

From: Kelly Grizzle <[email-masked]>
Date: Tue, 5 Feb 2013 19:24:39 +0000

I agree with you here, Chris.  I think that hiding data within an endpoint raises the level of complexity substantially and that SCIM shouldn't go there unless there are very strong needs.

My statements around the server not being required to return all attributes was more geared toward what the server is capable of storing.  For example, if the server does not support the "title" attribute, this would not be persisted on a POST/PUT/PATCH.

--Kelly

From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Phillips
Sent: Tuesday, February 05, 2013 8:42 AM
To: [email-masked]
Subject: [scim] really a security context question --> Re: Normative Schema Representation Example

Shelly,

As a dialog starter:

Chris.

Thanks, Kelly.

--Kelly