Do you think targeting addresses the namespace issue? I don't see how that works unless the schema at each endpoint is different which means the namespace would also be different, I guess.
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Kelly Grizzle
Sent: Wednesday, April 11, 2012 6:12 AM
Subject: RE: group namespaces
Have you seen the targeting proposal yet? I'm not sure if this would address your need, but multi-tenancy is was considered with targeting.
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Leif Johansson
Sent: Wednesday, April 11, 2012 3:15 AM
To: Cloud Directory
Subject: Re: group namespaces
On Apr 11, 10:00 am, Samuel Erdtman <sam...@erdtman.se> wrote:
> Not completely sure, but I think that Morteza means
> POST /another/namespace/Groups
> I.e. Namespace/Tenant comes before (in url) what is defined by the
> SCIM 1.0 specification. This is defined as Base URL in
OK I guess that makes sense. This seems like something that needs to be clarified in the spec :-)
> On Wed, Apr 11, 2012 at 9:50 AM, Leif Johansson <le...@mnt.se> wrote:
> > On Apr 10, 11:59 pm, "Morteza Ansari (moransar)"
> > <moran...@cisco.com>
> > wrote:
> >> Hi Leif,
> >> Welcome to the group! I was hoping to catch up with you in Paris,
> >> but the week went by so quickly.
> > Quite
> >> In general the namespace is not defined as part of the SCIM spec
> >> itself as there were two scenarios that were discussed. The first
> >> case is when the namespace is global (giant single tenant) where a
> >> username is a username and it must be unique globally. The other
> >> case was when namespace is segmented and for that case
> >> (multi-tenant), the URL is the qualifier to the namespace to make it globally unique.
> > Ah so in that case you'd (say) POST to /Groups/a/nother/namespace/
> > to create a group for instance? If so the spec isn't exactly clear
> > on that option...
> >> I have not heard of anyone requesting extension for solving the
> >> namespace. Though your use case might be a new one driving such
> >> requirement. I would be interested to hear if the URL
> >> qualification solves your use case.
> > Using the URI would be preferred!
> >> How extensions are managed is pretty vague and is one of the
> >> reasons we wanted to move this work to IETF to define better process around it.
> > OK good then. We should talk about that some more. There are other
> > groups talking about a post-rfc2252 attribute language.
> >> And I will skip answering your last question ;-)
> > Excellent!
> >> Cheers,
> >> Morteza
> >> -----Original Message-----
> >> From: firstname.lastname@example.org
> >> [mailto:email@example.com] On Behalf Of Leif
> >> Johansson
> >> Sent: Tuesday, April 10, 2012 2:41 PM
> >> To: Cloud Directory
> >> Subject: group namespaces
> >> I'm fairly new to this group (although not to some of the work that
> >> is tangential to SCIM - some of you know me from IETF and other
> >> places) so forgive me if this has been raised before....
> >> I have an application where groups have names that are part of
> >> managed name spaces - mostly used for managing access control. As I
> >> started to implement a SCIM server for this application it dawned
> >> on me (call me stupid for not realizing this) that SCIM doesn't
> >> have any concept of name space for any of its standard resources. I
> >> realize that it would be fairly easy to define an extension schema
> >> for groups that define 'name_space' attribute but since all clients
> >> would have to implement this extension in order to create groups
> >> (since name_spaces are the basis for ACLs) in my implementation,
> >> chances for interoperability would be somewhat limited.
> >> Here are some questions...
> >> - has name spaces for groups or any other type of resource been
> >> discussed?
> >> - is anyone else considering similar extensions?
> >> - how is an extension schema documented - i.e what does rfc2252
> >> look like for SCIM?
> >> - should I just give up and roll my own API?
> >> Cheers Leif