Subject: [scim] Use cases for enhancements to externalID

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

I would like to ask anyone that have real use cases for multi-valued or typed/complex externalID to bring them to the WG.  I think it would greatly help better define this and make a decision on whether we need to extend the current definition or just clarify it.

Cheers,
Morteza

---

From: Grahame Grieve <[email-masked]>
Date: Thu, 11 Sep 2014 15:58:38 +1000

it's not clear what externalId is for. In a distributed system, it's
not unlikely that there will be multiple relevant other identifiers -
is there some notion of which is primary? For instance, I need to map
between the User resource in the SCIM interface, and a Patient record
in a different interface, so that the security engine knows that this
user is the same as this patient. Should that be externalId, or should
it be somewhere else (an extension?). I didn't think that the
definition of external id was quite clear enough to be sure. But if I
said to use externalId for that, what happens to other uses of
externalId - same user on a different user record? (which is why I
think I shouldn't use externalId for that)

Earlier in the thread, someone said that multiple identifiers might
leak between different clients. Well, you might want them to share the
multiple identifiers, but limiting identifier to one doesn't solve the
leakage problem - so I don't think it's a reason to limit it to one.

Still, multiple identifiers are always a problem - how do you tell
them apart? Actually, I looked for a set of links that identified
related records to the user - e,g, href= + rel=. I would prefer this
over the existing approach

Grahame

On Thu, Sep 11, 2014 at 9:45 AM, Morteza Ansari (moransar)
<[email-masked]> wrote:
> I would like to ask anyone that have real use cases for multi-valued or
> typed/complex externalID to bring them to the WG.  I think it would greatly
> help better define this and make a decision on whether we need to extend the
> current definition or just clarify it.
>
>
> Cheers,
> Morteza
>
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim
>

-- 
-----
http://www.healthintersections.com.au /
[email-masked] / +61 411 867 065

---

From: Chuck Mortimore <[email-masked]>
Date: Thu, 11 Sep 2014 07:53:16 -0700

externalid is there to provide a surrogate primary key for the scim entity so it can be more easily addressed by scim consumers or federation services. 

For example, if you are trying to provide single sign-on to a cloud service, it is often more convenient for the IDP to use its local identifier for the user, rather than to update its schema and store the identifier used by the cloud service.   So - it(or the provisions service it is paired with) would use scim to set its primary id for the user as externalid and send that as the subject of a SAML assertion.   

- cmort

> On Sep 10, 2014, at 10:58 PM, Grahame Grieve <[email-masked]> wrote:
>

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Mon, 22 Sep 2014 22:34:12 +0000

As far as I can tell nobody brought up any use cases for adding support
for multi-valued or complex externalID.  I take that as consensus to
clarify the spec and stating this is a single valued attribute and move
forward.  If anyone objects to this, please speak up now.

Cheers,
Morteza

On 9/11/14, 7:53 AM, "Chuck Mortimore" <[email-masked]> wrote:

>externalid is there to provide a surrogate primary key for the scim
>entity so it can be more easily addressed by scim consumers or federation
>services. 
>
>For example, if you are trying to provide single sign-on to a cloud
>service, it is often more convenient for the IDP to use its local
>identifier for the user, rather than to update its schema and store the
>identifier used by the cloud service.   So - it(or the provisions service
>it is paired with) would use scim to set its primary id for the user as
>externalid and send that as the subject of a SAML assertion.
>
>- cmort
>
>> On Sep 10, 2014, at 10:58 PM, Grahame Grieve
>><[email-masked]> wrote:
>>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 22 Sep 2014 15:48:16 -0700

If it is single valued, which client may set the value?

How is it bound?

Phil

> On Sep 22, 2014, at 15:34, "Morteza Ansari (moransar)" <[email-masked]> wrote:
>

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Mon, 22 Sep 2014 22:56:22 +0000

Any client that is authorized to modify the value.  Not sure what you mean
by bound.  No attribute is bound to a specific client, this is no
different (given lack of new use cases).

Cheers,
Morteza

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Mon, 22 Sep 2014 23:36:14 +0000

Can you please expand?

On 9/22/14, 4:33 PM, "Grahame Grieve" <[email-masked]> wrote:

>No, not for a complex external id, but I would like to have a set of
>links for the user.
>
>Grahame
>
>> On 23 Sep 2014, at 8:34 am, "Morteza Ansari (moransar)"

---

From: Phil Hunt <[email-masked]>
Date: Mon, 22 Sep 2014 16:58:13 -0700

I think I’m being a bit pedantic too, but I’m just anticipating questions down the road here. 

From the spec...

externalId
      A String that is an identifier for the resource as defined by the
      client.  The "externalId" may simplify identification of the
      resource between client and service provider by allowing the
      client to use a filter to locate the resource with its own
      identifier, obviating the need to store a local mapping between
      the local identifier of the resource and the identifier used by
      the service provider.  Each resource MAY include a non-empty
      "externalId" value.  The value of the "externalId" attribute is
      always issued by the client and MUST NOT be specified by the
      service provider.  The service provider MUST always interpret the
      externalId as scoped to the client's tenant.  While the server
      does not enforce uniqueness, it is assumed that the value's
      uniqueness is controlled by the client setting the value.  See
      Section 9 for additional considerations regarding privacy.

The text that gives me concern is:
     The value of the "externalId" attribute is
      always issued by the client and MUST NOT be specified by the
      service provider.  The service provider MUST always interpret the
      externalId as scoped to the client's tenant.

The problem I’m having is that externalId is single-valued and bound to the tenant. This simple requirement has a wide amount of interpretation and methods for implementation. I’m worried about a lot of incompatibilities emerging here.

What happens if multiple security domains (remember SCIM is cross-domain) are referencing the same user resource? Are they each allowed to have a single-value?  Thus the server is required to virtualize the fact that there is only a single value but will have to maintain multiple externalId instances based on domain/tenancy whatever?

This definition has implied virtualization and security characteristics that no other attribute type has.  Are we really wanting to do something special here? Are we saying that there can be access control and that for any particular attribute, the server may accept or decline values (in which case should it ignore or throw an error).

Other options:
1.  Multi-valued plus typing - any client can do what ever they want technically. In practice we set type value to someting that indicates a domain or format.
2.  Single-valued immutable - first client to set the value wins.  This is not helpful to second, or third to the table clients who also want to assign an externalId
3.  Create a new data type/access control definition that allows specific values to be assigned to clients.

Phil

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

---

From: Grahame Grieve <[email-masked]>
Date: Tue, 23 Sep 2014 11:08:49 +1000

...from the right email this time...

Sure, I can expand. A couple of points:

Most uses of scim will use the user/group in the context of some wider set
of functionality. Either they can extend the scim user - a long way - or
they can link the user to their other context. For instance, in the context
of health, for which I am writing what will be a widely used spec, the user
will correspond to either a patient or a healthcare provider (or perhaps
both, though most systems keep them far apart even when they're the same
person). How is this link to be established? It could either be from the
scim user to the extarnal resource, or to the other way around, or both.
I'm thinking about which would be better, but if it's from the user to
the external resource:
- it could be by reusing the external id. But the external id as described
by the spec and /or Phil's comments is not suitable for this use, and it
has other uses
- it could be by putting extensions into the resource. Perhaps this is the
intent, though I'm not sure why extarnalId is very different
- it could done be adding a link property that has rel-type and href. I'd
use related, but there's a bunch of interesting ones here:
http://www.iana.org/assignments/link-relations/link-relations.xhtml.

That's the second - these links are used for hateos. I suppose that you
could confine them to the http header (in fact, we could use it that way in
my context too), but there's kind of a difference between workflow uses and
uses related to meaning - that's why HTML pages can include links in the
page itself, not just in the headers,,and why I think it would be a good
idea to add them to the resource itself.mpossibly in the meta element

A couple of further comments:
- I'm still thinking about how the link should be made, and if the spec
already answers think I missed it. But I think it will be a common use case.
- I'm also interested in the by-play between links on the http headers, and
links in the resource as well. Is this as good an idea as I made it sound?

Grahame

On Tuesday, September 23, 2014, Morteza Ansari (moransar) <
[email-masked]> wrote:

> Can you please expand?
>
>
>
> On 9/22/14, 4:33 PM, "Grahame Grieve" <[email-masked] <javascript:;>>
> wrote:
>
> >><[email-masked] <javascript:;>> wrote:
> >>
> >>> On 9/11/14, 7:53 AM, "Chuck Mortimore" <[email-masked]
> <javascript:;>>
> >>>wrote:
> >>>
> >>>> <[email-masked] <javascript:;>> wrote:
> >>>>
> >>>> <[email-masked] <javascript:;>> wrote:
> >>>>> [email-masked] <javascript:;>
> >>>> [email-masked] <javascript:;> / +61 411 867 065
> >>>>
> >>>> [email-masked] <javascript:;>

-- 
-----
http://www.healthintersections.com.au / [email-masked]
/ +61 411 867 065

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Fri, 26 Sep 2014 23:20:58 +0000

Speaking as an individual:

Sorry Phil, but I am still confused here.  Not sure what it means for multiple clients to have provisioning or management rights to the same object.  How is this different from first name?  In your scenario one client wants to set externalID to “x” and another client wants to set it to “y”, how is that different from the first client wanting to set first name to “John” and second client trying to set it to “Johny”?

I see the use case of a hub and spoke provisioning (or cross domain), where a client may want to provision to multiple SCIM servers (wasn’t this the old targeting use case?).  In that case the client certainly could manage that additional data internally if it needs it (not using externalID) and have a mapping between its different ID spaces and the target SCIM server where it will be provisioning.

Cheers,
Morteza

From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Date: Monday, September 22, 2014 at 4:58 PM
To: Morteza Ansari <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Chuck Mortimore <[email-masked]<mailto:[email-masked]>>, Grahame Grieve <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scim] Use cases for enhancements to externalID

externalId

Other options:

Phil

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

On Sep 22, 2014, at 3:56 PM, Morteza Ansari (moransar) <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,
Morteza

On 9/22/14, 3:48 PM, "Phil Hunt" <[email-masked]<mailto:[email-masked]>> wrote:

How is it bound?

Phil

On Sep 22, 2014, at 15:34, "Morteza Ansari (moransar)"
<[email-masked]<mailto:[email-masked]>> wrote:

Cheers,
Morteza

On 9/11/14, 7:53 AM, "Chuck Mortimore" <[email-masked]<mailto:[email-masked]>>
wrote:

externalid is there to provide a surrogate primary key for the scim
entity so it can be more easily addressed by scim consumers or
federation
services.

identifier used by the cloud service.   So - it(or the provisions
service

- cmort

On Sep 10, 2014, at 10:58 PM, Grahame Grieve
<[email-masked]<mailto:[email-masked]>> wrote:

Grahame

On Thu, Sep 11, 2014 at 9:45 AM, Morteza Ansari (moransar)
<[email-masked]<mailto:[email-masked]>> wrote:
I would like to ask anyone that have real use cases for multi-valued
or
typed/complex externalID to bring them to the WG.  I think it would
greatly
help better define this and make a decision on whether we need to
extend the
current definition or just clarify it.

Cheers,
Morteza

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

--
-----
http://www.healthintersections.com.au /
[email-masked]<mailto:[email-masked]> / +61 411 867 065

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

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

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

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Sat, 27 Sep 2014 00:03:14 +0000

Thanks for the additional info.  Wouldn’t this be a classic case of schema extension though?  In your example you probably need two distinct schema extensions, one for “patient” and another for “provider” where each extension defines the necessary attributes and semantics for that type of user and if the user happens to be both a patient in one context and a provider in another context, will have both extensions.  I don’t see how that links with externalID unless you consider each of these providers a different authoritative source in which case you are going down the distributed attribute provider which is probably a whole net set of use cases (interesting use cases though).

Cheers,
Morteza

From: Grahame Grieve <[email-masked]<mailto:[email-masked]>>
Date: Monday, September 22, 2014 at 6:08 PM
To: Morteza Ansari <[email-masked]<mailto:[email-masked]>>
Cc: Chuck Mortimore <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scim] Use cases for enhancements to externalID

Most uses of scim will use the user/group in the context of some wider set of functionality. Either they can extend the scim user - a long way - or they can link the user to their other context. For instance, in the context of health, for which I am writing what will be a widely used spec, the user will correspond to either a patient or a healthcare provider (or perhaps both, though most systems keep them far apart even when they're the same person). How is this link to be established? It could either be from the scim user to the extarnal resource, or to the other way around, or both. I'm thinking about which would be better, but if it's from the user to the external resource:
- it could be by reusing the external id. But the external id as described by the spec and /or Phil's comments is not suitable for this use, and it has other uses
- it could be by putting extensions into the resource. Perhaps this is the intent, though I'm not sure why extarnalId is very different
- it could done be adding a link property that has rel-type and href. I'd use related, but there's a bunch of interesting ones here: http://www.iana.org/assignments/link-relations/link-relations.xhtml.

That's the second - these links are used for hateos. I suppose that you could confine them to the http header (in fact, we could use it that way in my context too), but there's kind of a difference between workflow uses and uses related to meaning - that's why HTML pages can include links in the page itself, not just in the headers,,and why I think it would be a good idea to add them to the resource itself.mpossibly in the meta element

A couple of further comments:
- I'm still thinking about how the link should be made, and if the spec already answers think I missed it. But I think it will be a common use case.
- I'm also interested in the by-play between links on the http headers, and links in the resource as well. Is this as good an idea as I made it sound?

Grahame

On Tuesday, September 23, 2014, Morteza Ansari (moransar) <[email-masked]<mailto:[email-masked]>> wrote:
Can you please expand?

On 9/22/14, 4:33 PM, "Grahame Grieve" <[email-masked]<javascript:;>> wrote:

>><[email-masked]<javascript:;>> wrote:
>>
>>> On 9/11/14, 7:53 AM, "Chuck Mortimore" <[email-masked]<javascript:;>>
>>>wrote:
>>>
>>>> <[email-masked]<javascript:;>> wrote:
>>>>
>>>> <[email-masked]<javascript:;>> wrote:
>>>>> [email-masked]<javascript:;>
>>>> [email-masked]<javascript:;> / +61 411 867 065
>>>>
>>>> [email-masked]<javascript:;>

--
-----
http://www.healthintersections.com.au / [email-masked]<mailto:[email-masked]> / +61 411 867 065

---

From: Phil Hunt <[email-masked]>
Date: Fri, 26 Sep 2014 18:06:49 -0700

I think an externid for enterprise to cloud and for saml subject matching (as Chuck mentioned) can create conflicts. 

I also wonder what happens over time when cloud to cloud scenarios occur. Who then controls the value? Who is the owning client is not really defined well in a peer to peer case. 

I am neutral on this but I do find the current language underspecified if it is to be single valued. 

Phil

> On Sep 26, 2014, at 17:03, "Morteza Ansari (moransar)" <[email-masked]> wrote:
> 
> From: Grahame Grieve <[email-masked]>
> To: Morteza Ansari <[email-masked]>
> Cc: Chuck Mortimore <[email-masked]>, "[email-masked]" <[email-masked]>
>> On Tuesday, September 23, 2014, Morteza Ansari (moransar) <[email-masked]> wrote:
>> Can you please expand?
>> 
>> 
>> 
> http://www.healthintersections.com.au / [email-masked] / +61 411 867 065

---

From: Grahame Grieve <[email-masked]>
Date: Sat, 27 Sep 2014 20:20:24 +1000

> Wouldn’t this be a classic case of schema
> extension though?  In your example you probably need two distinct schema
> extensions, one for “patient” and another for “provider” where each
> extension defines the necessary attributes and semantics for that type of
> user and if the user happens to be both a patient in one context and a
> provider in another context, will have both extensions.

no, because there are already resources for these with their own existing
restful interface, and a bunch of defined behaviours etc. So all that is
wanted in the SCIM user object is to link to the existing patient or
provider resource

> I don’t see how
> that links with externalID unless you consider each of these providers a
> different authoritative source in which case you are going down the
> distributed attribute provider which is probably a whole net set of use
> cases (interesting use cases though).

no, it probably doesn't, as I read more, but is it necessary to add a
schema extension to link a user to related external resources? If
so, then that's what I'll have to do - but it seems to me that this
will be a common extension. What, for instance, would facebook,
dropbox or paypal do if they decided to implement SCIM? They would
be in the same position, right - need to link from the SCIM user
to the logical resource that links to the user in their business
environment

Grahame

---

From: Phil Hunt <[email-masked]>
Date: Sat, 27 Sep 2014 09:44:04 -0700

I’m thinking out loud here (and may have this very wrong)….

The sense that I get from the group is that externalId is intended only as a lookup key for clients. Assigning meaning to externalId is not correct usage.

It is ok to use externalId={somekey} as a filter, but we should NOT be using it for the purpose of holding a defined identifier value. 

Wrong: “We put patient number in externalId so we can retrieve patient numbers”.  
Correct: Saying we put patient numbers in externalId so we can “locate” patients would be correct usage. 

Valid: give me the record whose externalId is 1234. 
Invalid: what is the externalId of this record.

Thinking of it this way, having externalId be multi-valued should not matter.  Nor should it matter which value is which.  What matters is that a match can be found for a value.

A User schema can be extended to have an attribute patientNum as a specific attribute. But it may also be useful to add the value to externalId if the client might not know if the record has been extended with the attribute. It can use externalId as the general attribute to match keys against.

ExternalId is not meant to be retrieved (it might even be write only or not returnable). It’s purpose is for matching only.

Phil

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

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Mon, 29 Sep 2014 05:13:43 +0000

Speaking as an individual: Got it.  But even in this scenario, it is an
schema extension but the new schema is simply a pointer (URL/URI?) to
patient and provider resources.

On 9/27/14, 3:20 AM, "Grahame Grieve" <[email-masked]>
wrote:

>> Wouldn¹t this be a classic case of schema
>> extensions, one for ³patient² and another for ³provider² where each
>> I don¹t see how

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Mon, 29 Sep 2014 05:19:52 +0000

Here is an example of how externalID could be used for chaining ID’s cross multiple providers.  Note that this does NOT cover the case where you go from many to one though.

The first client provisions users to service provider A from AD using GUID as externalID.  Service provider A provisions to service provider B and uses its “id” as “externalID”, and so on.  The only thing unique about externalID is the fact the client provisioning uses as a reference back to its own objects in its store.  Obviously as I said this excludes many to one scenarios which really was the basic idea for targeting and I am sure sooner or later this will come up, but I personally believe that can be handled using extensions semantics we have defined for the schema and protocol.

I fully agree with you that the current language is underspecified and should be tweaked to be more clear.

Cheers,
Morteza

From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 26, 2014 at 6:06 PM
To: Morteza Ansari <[email-masked]<mailto:[email-masked]>>
Cc: Grahame Grieve <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Chuck Mortimore <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scim] Use cases for enhancements to externalID

Phil

On Sep 26, 2014, at 17:03, "Morteza Ansari (moransar)" <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,
Morteza

Grahame

---

From: Grahame Grieve <[email-masked]>
Date: Mon, 29 Sep 2014 17:08:07 +1000

well, it's an extension, I'll define one. Just seemed to me that it
would be used often enough to be added to the base schema

Grahame

---

From: Erik Wahlström <[email-masked]>
Date: Mon, 29 Sep 2014 09:00:22 +0000

My reasonings around externalID. in compact form :)

- I think that Thomas was right on the money when he said. "SCIM server should obey Postel's law.”. Core value is that is should be as simple as possible to implement and to call SCIM service providers. I would like to just send a SCIM core user that I have (of have found somewhere in my infrastructure :)) and parse the response without getting a bunch of errors if it’s a valid core user.
- I also think that externalId is important to return. Makes it easier to develop and verify the setup.
- Don’t make externalID multi-valued. It opens up a lot of questions around multi-tenancy from implementors that I think should be out of scope of the spec. We should not build into SCIM possibility for more users to clash around one specific tenants users. If a service provider have that scenario then it should be handled there. Not in spec. Once again, keep it simple to read, understand and to implement. If a client would like to use the externalID as subject in a SAML assertion, then it’s up to the service provider to match it against that client. I don’t really see (I’m still to be convinced :)) what’s wrong with the current text around externalId in the core schema. Seems clear to me that a service provider should return a SCIM user that’s crafted against the current calling client when it comes to exernalID.

Sorry for semi-hi-hacking the thread. 
Cheers
Erik

---

From: Phil Hunt <[email-masked]>
Date: Mon, 29 Sep 2014 08:42:47 -0700

Ok. Thanks for all your input. I am feeling the group is leaning towards leave as is. 

I am happy to look at the text and make sure servers can do a different value per subject/domain. I think it does a good job, but will confirm. One issue is what happens in the second client domain. Does it behave as if the value was never set?

Eg does a sfdc client(for saml subj match) see a different value than an enterprise client?

Remember scim protocol client <> enterprise client. They both use scim and both are technically protocol clients. However the implied owner here is the enterprise which some may be thinking is THE ONLY client. :-)

Phil

> On Sep 29, 2014, at 2:00, Erik Wahlström <[email-masked]> wrote:
>