Subject: [scim] ExternalId - characteristics.

From: Phil Hunt <[email-masked]>
Date: Fri, 5 Sep 2014 16:30:42 -0700

Looking at the definition for the externalId attribute, I see:
      {
        "name" : "externalId",
        "type" : "string",
        "multiValued" : false,
        "description" : "An identifier for the Resource as defined by the Service Consumer.",
        "required" : true,
        "caseExact" : false,
        "mutability" : "readWrite",
        "returned" : "default",
        "uniqueness" : "none"
      },

Is this correct. Should it not be multi-valued and unique (although enforcement is assumed to be the client)?

I’m thinking multi-valued because there may be multiple clients associating with the same resource in the cloud.  Each clients wants to leave a unique identifier in externalId.

Any objections?

Phil

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

---

From: Leif Johansson <[email-masked]>
Date: Sat, 06 Sep 2014 10:15:18 +0200

On 2014-09-06 01:30, Phil Hunt wrote:
> Is this correct. Should it not be multi-valued and unique (although
> enforcement is assumed to be the client)?
> 

... no hats ...

> I’m thinking multi-valued because there may be multiple clients
> associating with the same resource in the cloud.  Each clients wants to
> leave a unique identifier in externalId.

Clearly you are correct.

> Any objections?

None. Good catch!

---

From: Erik Wahlström <[email-masked]>
Date: Sun, 7 Sep 2014 09:58:03 +0000

Current core spec states that the externalID is scoped to the client’s tenant. So it’s up to an implementor to handle multiple client’s externalId. Feels like a multiValued attribute bleeds information about different clients representations. Makes me think of transient/persistant IDs in SAML.

“…The service provider MUST always interpret the externalId as scoped to the client’s tenant…"

I would like to keep it as single valued attribute.

/ Erik

On 06 Sep 2014, at 01:30, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

      {
        "name" : "externalId",
        "type" : "string",
        "multiValued" : false,

Any objections?

Phil

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

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

---

From: Kelly Grizzle <[email-masked]>
Date: Mon, 8 Sep 2014 01:59:04 +0000

I agree with Erik.  We have gone back and forth over this a number of times.  The question about a multi-valued attribute is how do we represent the client for each value?  Perhaps through the "type" sub-attribute, but - as Erik mentioned - this could leak data between clients.  My vote would be to keep it single valued and leave it up to the server to handle the correct value for the client that is requesting.

--Kelly

From: scim [mailto:[email-masked]] On Behalf Of Erik Wahlström
Sent: Sunday, September 07, 2014 4:58 AM
To: Phil Hunt
Cc: SCIM WG
Subject: Re: [scim] ExternalId - characteristics.

Current core spec states that the externalID is scoped to the client's tenant. So it's up to an implementor to handle multiple client's externalId. Feels like a multiValued attribute bleeds information about different clients representations. Makes me think of transient/persistant IDs in SAML.

"...The service provider MUST always interpret the externalId as scoped to the client's tenant..."

/ Erik

      {

        "name" : "externalId",

        "type" : "string",

        "multiValued" : false,

        "required" : true,

        "caseExact" : false,

        "returned" : "default",

        "uniqueness" : "none"

      },

I'm thinking multi-valued because there may be multiple clients associating with the same resource in the cloud.  Each clients wants to leave a unique identifier in externalId.

Any objections?

Phil

@independentid

---

From: David Möbius <[email-masked]>
Date: Mon, 08 Sep 2014 09:12:51 +0200

+1

for multivalue and that it can have a name for each client.

Doesn anyone has a idear how to solve the problems if one user belongs 
to several clients but not all values should be seen by all clients?

David

On 06.09.2014 01:30, Phil Hunt wrote:
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
>
>
>
>
>
> [email-masked]

---

From: Phil Hunt <[email-masked]>
Date: Mon, 8 Sep 2014 07:11:39 -0700

I think the idea that certain values may need to be restricted to certain clients is an enhancement. It sounds like an access control feature. 

That said, it sounds like a security considerations issue. 

Phil

> On Sep 8, 2014, at 0:12, David Möbius <[email-masked]> wrote:
> 
> +1
> 
> Doesn anyone has a idear how to solve the problems if one user belongs to several clients but not all values should be seen by all clients?
> 
> David
>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 10 Sep 2014 11:17:59 -0700

Any feedback on this topic? I’ve heard very different conflicting opinions on whether externalId should be multi-valued.

Further, in the multi-value option you could say you say that each value should have a type.

I think we need more clarification on how this is to be used.

I am concerned that the notion that a single client controls externalId is fits only an initial deployment. I would expect that over time, mxn relationships will emerge where many clients connect or reference the same cloud user.  Having a separate externalId assigned by each different client involves a data type or access control model that SCIM currently doesn’t support.

For me, I can go either way…but that’s mainly because externalId is a bit mysterious to me.

Phil

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

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Wed, 10 Sep 2014 19:07:58 +0000

Wearing chair hat: I think we need to let use cases drive this.  What are
the use cases for defining externalId as a multi-valued attribute or
turning it into a complex attribute?

Now with implementor hat: in almost all cases I have come across, there is
a single authoritative source for the identity and hence a single value
for the externalID with no semantics to be enforced by the service
provider (etc. uniqueness) is all that is needed.  I am sure if we dig we
can come up with use cases in the larger context this would need to be
more complex, but why couldn¹t that be handled as an extension?

Cheers,
Morteza

On 9/10/14, 11:17 AM, "Phil Hunt" <[email-masked]> wrote:

>Any feedback on this topic? I¹ve heard very different conflicting
>opinions on whether externalId should be multi-valued.
>
>I am concerned that the notion that a single client controls externalId
>is fits only an initial deployment. I would expect that over time, mxn
>relationships will emerge where many clients connect or reference the
>same cloud user.  Having a separate externalId assigned by each different
>client involves a data type or access control model that SCIM currently
>doesn¹t support.
>
>For me, I can go either wayŠbut that¹s mainly because externalId is a bit
>mysterious to me.
>
>Phil
>
>@independentid
>www.independentid.com
>[email-masked]
>
>
>
>> I think the idea that certain values may need to be restricted to
>>certain clients is an enhancement. It sounds like an access control
>>feature. 
>> 
>>>> I¹m thinking multi-valued because there may be multiple clients

---

From: Phil Hunt <[email-masked]>
Date: Wed, 10 Sep 2014 12:25:40 -0700

Coud to cloud is the use case I was thinking of.

But its not clear to me the enterprise side of this is thought out well yet either — at least as far as privacy and security considerations go.

ExternalIds sound a lot like connector Ids. A bit scary, because in meta-directory days, accounts very quickly tended to have a connecter ID per relationship.

There is a lot of good and bad experiences here.  :-)

That’s why I’d like to have stronger definition of this value, its purpose, and security considerations.

Phil

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

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Wed, 10 Sep 2014 23:43:50 +0000

Totally agree on improving the language to get to a more clear definition.

Can you expand the cloud to cloud use case?  I actually don’t see why that
would require multi-valued attribute for that.

Cheers,
Morteza

On 9/10/14, 12:25 PM, "Phil Hunt" <[email-masked]> wrote:

>But its not clear to me the enterprise side of this is thought out well
>yet either — at least as far as privacy and security considerations go.
>
>ExternalIds sound a lot like connector Ids. A bit scary, because in
>meta-directory days, accounts very quickly tended to have a connecter ID
>per relationship.
>
>>> Further, in the multi-value option you could say you say that each
>>>value
>>> should have a type.
>>>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 10 Sep 2014 16:48:13 -0700

In the cloud, ownership becomes less clear. There may be many relationships with nodes acting more as peers. Is externalId even intended to be used here?

Phil

> On Sep 10, 2014, at 16:43, "Morteza Ansari (moransar)" <[email-masked]> wrote:
>

---

From: Erik Wahlström <[email-masked]>
Date: Thu, 11 Sep 2014 08:14:17 +0000

I think we are reading in more into the value then originally thought of. It’s meant to keep things like the DN or GUID of the AD user when provisioning them to the cloud so that it’s possible to use that attribute to reference the User in the cloud using a filter. I just tried to figure out a new name and renaming it to something more clear, but externalId is kinda good :)

Maybe we should change the last sentence in the externalId description to make it possible to have 2 different clients working against the same resource in the same tenant (if that’s a potential future use case).

From:

"The service provider MUST always interpret the externalId as scoped to the client’s tenant."

To:

"The service provider MUST always interpret the externalId as scoped to the authenticated client."

Just to make my self clear, I like the externalId to stay a singular attribute.

/ Erik

On 11 Sep 2014, at 01:48, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Phil

On Sep 10, 2014, at 16:43, "Morteza Ansari (moransar)" <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,
Morteza

On 9/10/14, 12:25 PM, "Phil Hunt" <[email-masked]<mailto:[email-masked]>> wrote:

That’s why I’d like to have stronger definition of this value, its
purpose, and security considerations.

Phil

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

On Sep 10, 2014, at 12:07 PM, Morteza Ansari (moransar)
<[email-masked]> wrote:

Wearing chair hat: I think we need to let use cases drive this.  What
are
the use cases for defining externalId as a multi-valued attribute or
turning it into a complex attribute?

Now with implementor hat: in almost all cases I have come across, there
is
a single authoritative source for the identity and hence a single value
for the externalID with no semantics to be enforced by the service
provider (etc. uniqueness) is all that is needed.  I am sure if we dig
we
can come up with use cases in the larger context this would need to be
more complex, but why couldn¹t that be handled as an extension?

Cheers,
Morteza

same cloud user.  Having a separate externalId assigned by each
different

For me, I can go either wayŠbut that¹s mainly because externalId is a
bit
mysterious to me.

Phil

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

Phil

+1

Doesn anyone has a idear how to solve the problems if one user
belongs
to several clients but not all values should be seen by all clients?

David

  {
    "name" : "externalId",
    "type" : "string",
    "multiValued" : false,
    "description" : "An identifier for the Resource as defined by
the Service Consumer.",
    "required" : true,
    "caseExact" : false,
    "mutability" : "readWrite",
    "returned" : "default",
    "uniqueness" : "none"
  },

I¹m thinking multi-valued because there may be multiple clients
associating with the same resource in the cloud.  Each clients wants
to
leave a unique identifier in externalId.

Any objections?

Phil

@independentid