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 <phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>> wrote:

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)" <moransar@cisco.com<mailto:moransar@cisco.com>> wrote:

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" <phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>> wrote:

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<http://www.independentid.com>
phil.hunt@oracle.com



On Sep 10, 2014, at 12:07 PM, Morteza Ansari (moransar)
<moransar@cisco.com> 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

On 9/10/14, 11:17 AM, "Phil Hunt" <phil.hunt@oracle.com> wrote:

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
phil.hunt@oracle.com



On Sep 8, 2014, at 7:11 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

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 <d.moebius@tarent.de> wrote:

+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:
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 <http://www.independentid.com>
phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>





_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

_______________________________________________
scim mailing list
scim@ietf.org<mailto:scim@ietf.org>
https://www.ietf.org/mailman/listinfo/scim

_______________________________________________
scim mailing list
scim@ietf.org<mailto:scim@ietf.org>
https://www.ietf.org/mailman/listinfo/scim