search

surfnet-niels / edupersonEntitlement-and-IsMemberOf-scoped-semantics

A RFC on scoping the semantics of the edupersonEntitlement and eduMember IsMemberOf attribute values
0 stars 0 forks source link

Group name #1

Open biancini opened 9 years ago

biancini commented 9 years ago

Hi Niels, I've looked at your document. I conceptually agree with scoping isMemberOf attribute. But the current definition [localGroupIdentifier] @ [domain od authoratative source] seems to be too restrictive to me. In fact the localGroupIdentified, imho, should contain a hierarchical structure.

So the definition could become: [localGroupPath:]*[localGroupIdentifier] @ [domain od authoratative source]

An example could be: openstack:admin:admin@garr.it

What do you think about this? Cheers, A.

surfnet-niels commented 9 years ago

Hi Andrea,

I agree. It should be able to handle more intelligent structures beyond flat. I wonder however if we should make requirements on the bit before the @ sign or leave that up to the local system if possible. There may be additional semantics according to the protocol used however, see later in my examples

Internally OpenConext uses this example format: urn:collab:group:surfteams.nl:nl:surfnet:diensten:coin-do-2010 Basically: [URN namespace] : [authoratative source] : [something local](here you would immediately see the Grouper stem structure for the local part ;)

In your format that would be: nl:surfnet:diensten:coin-do-2010 @ surfteams.nl

I is clear that both format are easily converted into each other. The @ format has the advantage that it does not require a registered URN namespace.

We choose the URN format however as the OpenSocial Protocol (which is also the basis for VOOT) does not allow "@", as that is an operator. We may face such issues with other protocols as well, so therefore I wonder if it would be good to actually have 2 versions that can be transformed into each other. I note SCIM does not seem to have an semantic restrictions on the identifiers, see http://www.simplecloud.info/specs/draft-scim-core-schema-01.html#anchor2

Other question that pops up is how this look in a URL format?

biancini commented 9 years ago

Well I think we should provide some requirement about group names. I guessed this was the main goal of this RFC-ish. So I agree not all systems are yet supporting the name convention we're discussing, but I think it is a good to share this so that all tools can adapt and in the end we will obtain a common naming convention.

Regarding @ format, URN and URL question, the current version of the draft does only provide the @ format names for isMemberOf. Did I get it right? In this case we should stick to this definition and systems (as OpenConext) should find a way to comply. Do you agree? In case, instead, we want to suggest different namings (@ format, URN and URL for instance), I think we should express this in the document.

surfnet-niels commented 9 years ago

Indeed I only wrote down the @ format, as I think we should move from VOOT to a scim version of VOOT. That would take away the restriction on using the @. It is however a protocol that is used in production by some already, so that poses a challenge. I would propose to write down the mapping schema anyway, as we will for sue at some point encounter a system that cannot deal with @

surfnet-niels commented 9 years ago

Another thought: should we propose a new attribute "scopedIsMemberOf" which also fixes and formalized the semantics?