Subject: [scim] Scim Extensions Question

From: SHAWN E SMITH <[email-masked]>
Date: Tue, 3 May 2016 13:23:30 -0400 (EDT)

I apologize if this is the wrong list to send this to, but...

I'm looking for some advice.  I know the question of extensions has bounced around a bit but I'm still unclear on how to deal with extended values for base types.

For instance, in our payroll system we have the notion of validation of an address and the validating document.  Because we can have multiple addresses for multiple purposes tying those extended fields back elements to the correct base object is a bit of a challenge.  I'd like a declarative way to do it rather than relying on order or something else easy to break and hard to understand.

For others who have gone through the exercise, can you please share how you dealt with this?

Thanks in advance,
Shawn

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
--Martin Fowler 

Shawn Smith
Director of Software Engineering
Administrative Information Services
814-321-5227
[email-masked]

---

From: Phil Hunt <[email-masked]>
Date: Tue, 3 May 2016 11:15:23 -0700

This isn’t the first time this has come up (adding sub-attributes to core schema attributes).

To do this would require a new SCIM specification extending the core schema.  Most likely it would be a working group document. This type of scenario can’t be handled within the current formal extension mechanism.

There is a set of attributes that seem to be common that we could add to the complex type (see Sec 2.4 of RFC7643).  These attributes might include:
* Verified on
* Verified by
* Verification method
* Level of confidence
* Valid until
* Etc.

There are real questions to discuss on the list.  
* Should these types attributes be shared cross-domain? - depends on how you interpret “verified” - consensus on this could be tricky. E.g. by who and for whom and for what purpose?  
* Are these values meaningful across domain?  
* What about simple attributes? Do we want to allow sub-attributes of these?

I would like to avoid creating a new extension mechanism that permits new sub-attributes to be added to existing complex attributes or simple attributes. I believe this will take SCIM into a much higher level of complexity (e.g. deeply nested schema or other methods). What we have now is a compromise between functionality and simplicity that was negotiated in the working group at some length. 

What can service providers do for now? Many have a need that is localized only. If you want to proceed without an expectation of inter-op of the new attributes while still supporting general inter-operability, here is my interpretation of the specs...

One of the foundational components of SCIM protocol is “robustness”. This means that service providers and clients should accept (and ignore) data they do not care about.  In theory while the spec does not permit it, I don’t see a problem with service providers adding these attributes as if they were part of the core schema.  If they choose to extend the standard core schema as discussed above, service providers should:
*  List the new attributes in the core schema as part of the schemas endpoint (so a client that supports the attributes can know they are supported)
*  Service providers should not require clients to support these attributes, nor should they throw errors if clients assert them.

These types of “additive" changes are probably going to work well. I would *strongly* avoid the temptation to rename or change the attribute type of standardized attributes.

I urge caution here. We won’t know how well the robust features work in SCIM2 in practice until after we get through the interop testing this month. My hope is we’ll have some real world data on how well non-standard issues such as this are handled in the real world. I am aware of a couple of implementations that have this issue now. I am curious to see the results of support for non-standard extensions.

Phil

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

> On May 3, 2016, at 10:23 AM, SHAWN E SMITH <[email-masked]> wrote:
> 
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: SHAWN E SMITH <[email-masked]>
Date: Tue, 3 May 2016 14:35:07 -0400 (EDT)

Thanks much for the feedback. We'd hoped to join the interop but the schedule caught up with us. 

I agree that modifying the core complex items is a bad idea. I like the purity and interoperability it provides. What I've done so far is added an index to the core elements that is not included in the schema though it is marshalled out in the JSON. I'm using that same index in the extensions to tie the values together. If folks need it they can access it, if not they can ignore it. Because the spec says that consumers should ignore what they don't understand, I think we still meet the compliance requirements. 

Again, thanks for taking the time to respond. 

Shawn 

"The programmer … works only slightly removed from pure thought-stuff. 
He builds his castles in the air, from air, creating by exertion of the imagination." 
— Fred Brooks 

Shawn Smith 
Penn State University 
814-321-5227 
[email-masked] 

From: "Phil Hunt" <[email-masked]> 
To: "SHAWN E SMITH" <[email-masked]> 
Cc: [email-masked] 
Sent: Tuesday, May 3, 2016 2:15:23 PM 
Subject: Re: [scim] Scim Extensions Question 

Phil 

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

On May 3, 2016, at 10:23 AM, SHAWN E SMITH < [email-masked] > wrote: 

Thanks in advance, 
Shawn 

Shawn Smith