Subject: [scim] Multiple external id values

From: Mark Dobrinic <[email-masked]>
Date: Mon, 5 Oct 2015 16:42:02 +0200

Hi Scim people,

While incorporating Scim client functionality towards a Scim Service
Provider, we've stumbled upon a limitation regarding our desired use of
externalId, that doesn't fit the current spec.

Our usecase involves managing multiple external id's, so that we can
both support multiple externalId's to multiple Scim Clients from one
Scim Service Provider, as well as let a Scim Client manage multiple
external id's with one Scim Service Provider.  Each external id lives
within the domain of a, well, domain. There are plenty of real world
examples where domain-scoped id's are used, so it seems no more than
natural to consider this with Scim as well.

For example, a user with id barbara has an externalId 'babs' in the
domain 'home', and externalId 'labarbara' in domain 'work'.

As I understand Scim as being as effective and simple as possible, we've
been using the extensibility of Scim to make this work. I can imagine
this to be a generic problem that more people are (or will be) facing.
Therefore, I'd like to propose our solution and would like to discuss
whether this could/should be considered a standard solution to a
standard problem, either in this form or something better.

What we did was introduce an extension "
urn:scim:schemas:extensions:external-ids:1.0"
that defines an attribute "externalIds",
is of type "complex",
is multiValued,
can be described as "External Identities of a user. Each External
Identity is scoped within its domain",
is optional,
and has the following sub-attributes:
- value : string value containing the value of the external id
- type : string value containing the domain of the external id

In JSON, it would look like this:

                {
                "schemas": [ "urn:scim:schemas:core:1.0",
"urn:scim:schemas:extensions:external-ids:1.0" ],
                "id":"2819c223-7f76-453a-919d-413861904646",
                "userName":"bjensen",
                "externalId":"bjensen",
                ....
                "urn:scim:schemas:extensions:external-ids:1.0": {
                    "externalIds": [
                        {
                            "value": "babs",
                            "type": "home"
                        },
                        {
                            "value": "labarbara",
                            "type": "work"
                        }]
                    }
                }

Note that we are adding to the baseline features of Scim, and not
changing anything existing.

I would like to hear your feedback on this, and I'm interested whether
this could be considered as a standard extension in upcoming Scim versions.

Thanks!

-- 
Regards,

Mark Dobrinic
Software Engineer and Identity Specialist
Twobo Technologies AB

[email-masked]
www.twobotechnologies.com

---

From: Phil Hunt <[email-masked]>
Date: Mon, 5 Oct 2015 08:17:41 -0700

This was discussed and the consensus was single value. 

What you can do is expose a different single value for each domain client your server talks to.  Thus domains cannot see each other's ids. The spec already suggests this as a security consideration for the id value. 

This would provide much better privacy characteristics and reduces propagation of PII. 

Phil

> On Oct 5, 2015, at 07:42, Mark Dobrinic <[email-masked]> wrote:
> 
> Hi Scim people,
> 
> While incorporating Scim client functionality towards a Scim Service Provider, we've stumbled upon a limitation regarding our desired use of externalId, that doesn't fit the current spec.
> 
> Our usecase involves managing multiple external id's, so that we can both support multiple externalId's to multiple Scim Clients from one Scim Service Provider, as well as let a Scim Client manage multiple external id's with one Scim Service Provider.  Each external id lives within the domain of a, well, domain. There are plenty of real world examples where domain-scoped id's are used, so it seems no more than natural to consider this with Scim as well.
> 
> For example, a user with id barbara has an externalId 'babs' in the domain 'home', and externalId 'labarbara' in domain 'work'.
> 
> As I understand Scim as being as effective and simple as possible, we've been using the extensibility of Scim to make this work. I can imagine this to be a generic problem that more people are (or will be) facing. Therefore, I'd like to propose our solution and would like to discuss whether this could/should be considered a standard solution to a standard problem, either in this form or something better.
> 
> What we did was introduce an extension " urn:scim:schemas:extensions:external-ids:1.0"
> can be described as "External Identities of a user. Each External Identity is scoped within its domain",
> is optional,
>                 "schemas": [ "urn:scim:schemas:core:1.0", "urn:scim:schemas:extensions:external-ids:1.0" ],
> Note that we are adding to the baseline features of Scim, and not changing anything existing.
> 
> 
> I would like to hear your feedback on this, and I'm interested whether this could be considered as a standard extension in upcoming Scim versions.
> 
> 
> Thanks!
> 
> -- 
> Regards,
> 
> Mark Dobrinic
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Mark Dobrinic <[email-masked]>
Date: Mon, 5 Oct 2015 17:39:30 +0200

Hi Phil,

Thanks for the quick response.

The resolution to expose a client specific externalId only works in half
the scenario's, where you have multiple clients all representing one
domain. In the other scenario, where one client representing multiple
domains is using one Scim Service Provider, the client actually relies
on the Service Provider to store multiple identities for its multiple
domains, so in that usecase it is multi-valued by design.

Do I get it right that this particular use case has not yet come up then?

Concerning the privacy cinsideration, given a trust relationship between
the Scim Service Provider and the Scim Client (quite some features are
based on this already), privacy characteristics of the solution are not
of primary concern here. The Scim Client could (should) actually take
over the responsibility for protecting privacy in this one.

Cheers!

Mark

On 05/10/15 17:17, Phil Hunt wrote:
> What you can do is expose a different single value for each domain
> client your server talks to.  Thus domains cannot see each other's
> ids. The spec already suggests this as a security consideration for
> the id value. 
>
> On Oct 5, 2015, at 07:42, Mark Dobrinic
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> Hi Scim people,
>>
>> Provider, we've stumbled upon a limitation regarding our desired use
>> of externalId, that doesn't fit the current spec.
>>
>> As I understand Scim as being as effective and simple as possible,
>> we've been using the extensibility of Scim to make this work. I can
>> imagine this to be a generic problem that more people are (or will
>> be) facing. Therefore, I'd like to propose our solution and would
>> like to discuss whether this could/should be considered a standard
>> solution to a standard problem, either in this form or something better.
>>
>> I would like to hear your feedback on this, and I'm interested
>> whether this could be considered as a standard extension in upcoming
>> Scim versions.
>>
>>
>> Thanks!
>>
>> -- 
>> Regards,
>>
>> Mark Dobrinic
>> [email-masked] <mailto:[email-masked]>

-- 
Regards,

Mark Dobrinic

---

From: Phil Hunt <[email-masked]>
Date: Mon, 5 Oct 2015 08:55:32 -0700

I did raise this issue. 

The consensus was one and one only. 

I do have a concern about multiple domains connecting to the same entity. 

Does one see this as a client hub controlling multiple cloud spokes. Or does one see this as multiple client spokes contributing to a common hub entity. 

The latter has PII propagation concerns. 

I suspect most for now only care about the former. 

Phil

> On Oct 5, 2015, at 08:39, Mark Dobrinic <[email-masked]> wrote:
> 
> Hi Phil,
> 
> The resolution to expose a client specific externalId only works in half the scenario's, where you have multiple clients all representing one domain. In the other scenario, where one client representing multiple domains is using one Scim Service Provider,       the client actually relies on the Service Provider to store multiple identities for its multiple domains, so in that usecase it is multi-valued by design.
> 
> Concerning the privacy cinsideration, given a trust relationship between the Scim Service Provider and the Scim Client (quite some features are based on this already), privacy characteristics of the solution are not of primary concern here. The Scim Client could (should) actually take over the responsibility for protecting privacy in this one.
> 
> Cheers!
> 
> Mark
> 
> 
> 
>

---

From: Mark Dobrinic <[email-masked]>
Date: Mon, 5 Oct 2015 19:05:09 +0200

In our particular case, you can indeed see that the client acts as a
hub, applying multiple external identities for multiple domains.

I totally agree that is is generally a bad idea to expose an identity
that is registered with a client for domain A, to a client for domain B.
Not for minimizing PII exposure primarily, but for exposing information
that weakens the linkability property of privacy with identifiers.

This is not what we try to solve though. It is that first case. We'd
like to use Scim towards a backend system for the client-as-hub-case.
The externalId attribute can not help with that.

That's why I try to raise a general solution that does.

Putting it in an extension as described is totally acceptable though. I
don't feel like disturbing the choices that were made through consensus,
but I do feel like coming up with a general solution for that
alternative usecase. Including possible privacy implications.

On 05/10/15 17:55, Phil Hunt wrote:
> Does one see this as a client hub controlling multiple cloud spokes.
> Or does one see this as multiple client spokes contributing to a
> common hub entity. 
>
> On Oct 5, 2015, at 08:39, Mark Dobrinic
>> The resolution to expose a client specific externalId only works in
>> half the scenario's, where you have multiple clients all representing
>> one domain. In the other scenario, where one client representing
>> multiple domains is using one Scim Service Provider, the client
>> actually relies on the Service Provider to store multiple identities
>> for its multiple domains, so in that usecase it is multi-valued by
>> design.
>>
>> Concerning the privacy cinsideration, given a trust relationship
>> between the Scim Service Provider and the Scim Client (quite some
>> features are based on this already), privacy characteristics of the
>> solution are not of primary concern here. The Scim Client could
>> (should) actually take over the responsibility for protecting privacy
>> in this one.
>>
>> Cheers!
>>
>> Mark
>>
>>
>>
>>
>>> <[email-masked]> wrote:
>>>
>>>> Hi Scim people,
>>>>
>>>> While incorporating Scim client functionality towards a Scim
>>>> Service Provider, we've stumbled upon a limitation regarding our
>>>> desired use of externalId, that doesn't fit the current spec.
>>>>
>>>> Our usecase involves managing multiple external id's, so that we
>>>> can both support multiple externalId's to multiple Scim Clients
>>>> from one Scim Service Provider, as well as let a Scim Client manage
>>>> multiple external id's with one Scim Service Provider.  Each
>>>> external id lives within the domain of a, well, domain. There are
>>>> plenty of real world examples where domain-scoped id's are used, so
>>>> it seems no more than natural to consider this with Scim as well.
>>>>
>>>> whether this could be considered as a standard extension in
>>>> upcoming Scim versions.
>>>>
>>>>
>>>> Thanks!
>>>>
>>>> -- 
>>>> Regards,
>>>>
>>>> Mark Dobrinic

-- 
Regards,

Mark Dobrinic