Subject: [scim] Cardinality

From: Ian Glazer <[email-masked]>
Date: Tue, 16 Aug 2016 10:28:35 -0400

Hey gang -

Coming out of the interop one thing that I'd definitely like to see is a
way to represent cardinality in the schema. Case in point, the spec states
that email is a multivalued attribute, but we only support a single email
address. In order to comply with the spec, we have to represent it as
mutlivalued and then we throw an error if someone tries to add more than
one. Not optimal. I suggest a schema attribute of MaximumCardinality of
type number. The number represents the maximum entries for a multivalued
attribute. If not set, then it is implied there is no limit.

-- 
Ian Glazer
Senior Director, Identity
+1 202 255 3166
@iglazer <https://twitter.com/iglazer>

---

From: Leif Johansson <[email-masked]>
Date: Tue, 16 Aug 2016 16:32:37 +0200

Is somebody maintaining an issue list somewhere? Maybe dump the current rfcs in github...

Skickat från min iPhone

> 16 aug. 2016 kl. 16:28 skrev Ian Glazer <[email-masked]>:
> 
> Hey gang -
> 
> Coming out of the interop one thing that I'd definitely like to see is a way to represent cardinality in the schema. Case in point, the spec states that email is a multivalued attribute, but we only support a single email address. In order to comply with the spec, we have to represent it as mutlivalued and then we throw an error if someone tries to add more than one. Not optimal. I suggest a schema attribute of MaximumCardinality of type number. The number represents the maximum entries for a multivalued attribute. If not set, then it is implied there is no limit.
> 
> -- 
> Ian Glazer
> @iglazer
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Eric Fazendin <[email-masked]>
Date: Tue, 16 Aug 2016 08:53:52 -0600

We have looked at the same issue, limiting emails to only a single value.
We were thinking about doing it by enforcing uniqueness on and requiring
the "type" subattribute and setting the canonicalValues for "type" to just
"work".

Obviously, this modifies the core schema, which slightly defeats the
purpose of a standardized schema, but it's the best option we could find.

<https://www.pingidentity.com>
<https://www.pingidentity.com>
Eric Fazendin
Sr. Product Manager
[email-masked]
c: +1 303.895.9628
Connect with us: 
<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
[image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter
logo] <https://twitter.com/pingidentity> 
<https://www.facebook.com/pingidentitypage> 
<https://www.youtube.com/user/PingIdentityTV> 
<https://plus.google.com/u/0/114266977739397708540> 
<https://www.pingidentity.com/en/blog.html>

---

From: Ian Glazer <[email-masked]>
Date: Tue, 16 Aug 2016 11:22:10 -0400

It would be good to have at least one more WG meeting so that we can get a
grab off all these items. It would also be good if said meeting was
scheduled such that Shalini and the Google team could attend.

---

From: Phil Hunt <[email-masked]>
Date: Tue, 16 Aug 2016 09:31:21 -0700

There is some history here. When I raised this (because it broke LDAP compatibility) the consensus was to support the vCARD and move schema ahead of LDAP. That meant complex attributes and multi-values despite LDAPs limitations.  At least that was how I understood the consensus at the time and the design inherited from SCIM 1.1.

I note that there is pressure relief in the spec because a SP does not have to retain multiple values (even though the schema says otherwise). The SP is free to “edit” the values it wants to keep. The client should not expect that the service provider keeps any value exactly as requested - that was part of the robust consideration as it avoided a lot of complex alternatives requiring clients to have to develop complex code by intensely interrogating schema and reacting to each setting difference.  Another example of this is telephone numbers and email addresses where the SP is required to attempt to normalize badly formed values — which means the SP is actively modifying data provided by the client.  E.g.
> Service providers SHOULD canonicalize the
>       value according to [RFC5321 <https://tools.ietf.org/html/rfc5321>], e.g., "[email-masked]" instead
>       of "[email-masked]".
> 
> Service providers SHOULD canonicalize the
>       value according to [RFC3966 <https://tools.ietf.org/html/rfc3966>] format, when appropriate.

Phil

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

> On Aug 16, 2016, at 8:22 AM, Ian Glazer <[email-masked]> wrote:
> 
> It would be good to have at least one more WG meeting so that we can get a grab off all these items. It would also be good if said meeting was scheduled such that Shalini and the Google team could attend.
> 
> On Tue, Aug 16, 2016 at 10:32 AM, Leif Johansson <[email-masked] <mailto:[email-masked]>> wrote:
> 16 aug. 2016 kl. 16:28 skrev Ian Glazer <[email-masked] <mailto:[email-masked]>>:
> 
>> Hey gang -
>> 
>> +1 202 255 3166 <tel:%2B1%20202%20255%203166>
>> @iglazer <https://twitter.com/iglazer>_______________________________________________
>> scim mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/scim <https://www.ietf.org/mailman/listinfo/scim>
> 
> 
> 
> -- 
> Ian Glazer
> @iglazer <https://twitter.com/iglazer>_______________________________________________
> scim mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/scim <https://www.ietf.org/mailman/listinfo/scim>

---

From: Kelly Grizzle <[email-masked]>
Date: Tue, 16 Aug 2016 18:37:54 +0000

I agree that we should at least have some way to indicate if an attribute has these types of limitations (like Ian said … the schema is a perfect place for this).  The question about what to do if someone doesn’t adhere to this also deserves some discussion.

I have a list of issues/thoughts from the interop that I was supposed to put on the list, but have not had a chance to yet.  Sorry!

What’s the best way to capture these?  The SCIM issue tracker?  Start a github project for tracking?  Just chase them down over email?  It would be good to have another meeting where we can figure out how to tackle these.

--Kelly

From: scim [mailto:[email-masked]] On Behalf Of Ian Glazer
Sent: Tuesday, August 16, 2016 10:22 AM
To: Leif Johansson <[email-masked]>
Cc: [email-masked] WG <[email-masked]>
Subject: Re: [scim] Cardinality

On Tue, Aug 16, 2016 at 10:32 AM, Leif Johansson <[email-masked]<mailto:[email-masked]>> wrote:
Is somebody maintaining an issue list somewhere? Maybe dump the current rfcs in github...

Skickat från min iPhone

16 aug. 2016 kl. 16:28 skrev Ian Glazer <[email-masked]<mailto:[email-masked]>>:
Hey gang -

--
Ian Glazer
Senior Director, Identity
+1 202 255 3166<tel:%2B1%20202%20255%203166>
@iglazer<https://twitter.com/iglazer>
_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scim

--
Ian Glazer
Senior Director, Identity
+1 202 255 3166
@iglazer<https://twitter.com/iglazer>

---

From: Leif Johansson <[email-masked]>
Date: Tue, 16 Aug 2016 21:22:54 +0200

Skickat från min iPhone

> 16 aug. 2016 kl. 17:22 skrev Ian Glazer <[email-masked]>:
> 

The WG is already closed down but that doesn't matter since you can still do errata. 

My suggestion is still to gather up issues and do one big revision instead of a piecemeal approach.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 16 Aug 2016 21:23:45 +0200

Skickat från min iPhone

> 16 aug. 2016 kl. 20:37 skrev Kelly Grizzle <[email-masked]>:
> 

+1 for github issues

---

From: Shelley <[email-masked]>
Date: Wed, 24 Aug 2016 15:24:23 -0500

>
> What’s the best way to capture these?  The SCIM issue tracker?  Start a
> github project for tracking?  Just chase them down over email?  It would be
> good to have another meeting where we can figure out how to tackle these.
>
> +1 for github issues
>

We have been recently been reviewing the SCIM 2.0 specification in detail,
and have also noticed a few ambiguities and potential mistakes in the
specification that we would like to log. Will there be an issue tracker
available soon, or should we continue to post any issues to this mailing
list?

On Tue, Aug 16, 2016 at 2:23 PM, Leif Johansson <[email-masked]> wrote:

> I agree that we should at least have some way to indicate if an attribute
> has these types of limitations (like Ian said … the schema is a perfect
> place for this).  The question about what to do if someone doesn’t adhere
> to this also deserves some discussion.
>
>
>
> I have a list of issues/thoughts from the interop that I was supposed to
> put on the list, but have not had a chance to yet.  Sorry!
>
>
>
> What’s the best way to capture these?  The SCIM issue tracker?  Start a
> github project for tracking?  Just chase them down over email?  It would be
> good to have another meeting where we can figure out how to tackle these.
>
>
> +1 for github issues
>
>
>
> --Kelly
>
>
>
> *From:* scim [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Ian Glazer
> *Sent:* Tuesday, August 16, 2016 10:22 AM
> *To:* Leif Johansson <[email-masked]>
> *Cc:* [email-masked] WG <[email-masked]>
> *Subject:* Re: [scim] Cardinality
>
>
>