Shibboleth Developers

Issue  -- entitlements

Scott's  comments on the original proposal:

At 1:53 PM -0500 12/17/01, Scott Cantor wrote:
> If eduPersonEntitlement is meant to be a general attribute, then it's
> namespace isn't urn:xSTOR4 but urn:mace.eduPerson (or whatever).
>
> And you really want the values to be instrinsically unique, so you
> should just define it as urn:xSTOR5:contract1234 (or whatever URI you
> like) and be done with it. Then you specify the AttributeValue's
> xsi:type as anyURI (or probably you define it as a sequence of same).

> So I see two proposals I find reasonable for this general idea of
> externally defined groups (call it entitlement or whatever you want, it
> all feels the same to me):
>
> 1) It's useful to collect the notion of these groups under a single
> heading in the attribute-space, so we should define a single attribute
> within MACE to carry it. This is entirely independent from the decision
> to create eduPersonEntitlement in LDAP. That's a separate decision, in
> my opinion.
>
> <complexType name="EntitlementType">
>    <sequence>
>       <any namespace="##any" processContent="lax" minOccurs="0"
> maxOccurs="unbounded"/>
>    </sequence>
>    <attribute name="URI" type="anyURI" use="required"/>
> </complexType>
>
> <complexType name="eduPersonEntitlementType">
>    <sequence>
>      <element name="Entitlement" type="ep:EntitlementType"
> maxOccurs="unbounded"/>
>    </sequence>
> </complexType>
>
> Eg:
>
> <Attribute AttributeName="eduPersonEntitlement"
>      AttributeNamespace="urn:mace:eduPerson">
>    <AttributeValue xsi:type="ep:eduPersonEntitlementType">
>       <Entitlement URI="urn:mace:xSTOR5.org:contract1234"/>
>    </AttributeValue>
> </Attribute>
>
>
> 2) Shibboleth has no need to group such entitlements under a single
> heading.
> (This is still basically my opinion.)
>
> Eg:
>
> <Attribute AttributeName="contract1234"
>      AttributeNamespace="urn:mace:xSTOR5.org:contracts">
>    <AttributeValue/>
> </Attribute>
>
> Any such attribute could specify its own xsi:type and schema if value
> content was needed.

Both of these are improvements on my original proposal.

I've heard another comment about entitlement:

-- the use of the urn:mace namespace (rather than the original 
proposal of urn:XSTOR5) will be a lot easier on info vendors, because 
they won't have to write an RFC to get their own namespace.

I don't see any "structure of names" issues to differentiate these 
two proposals.

So, I begin wondering how these might be used at the  origin and  at 
the target.

At the AA, its  probably important to think about making it easier to 
organize the  various ARPs for  presentation to the browser user 
(either the local administrator, or someone using myAA). As long as 
the UI allows me to organize the ARPs in a way that makes  sense  for 
me (eg like the Bookmarks presentation in a browser),  there's 
probably not an  issue.

At the  target, we've got to think about both the AAPs and the policy 
rules used by the RM. Proposal 1  would  have an AAP  that looked 
something like this:

brown.edu can assert urn:mace:xSTOR5.org:contract1234  (attribute value)

while proposal 2 would have an AAP something like this:

brown.edu can assert "urn:mace:xSTOR5.org:contracts : contract1234" 
value +  name

Both  of these make me a little  uncomfortable (see follow note on 
AAs and  the RM).

The policy rule under Proposal 1  would look something  like  this:

(SecurityDomain)(attribute value)

and under Proposal 2 would look like this:

(SecurityDomain)(attribute value)(attribute name)

(again, see the other note). For all  of the other  attributes, I 
think we're at the point where the policy rule would  look like 
Proposal 1. Which makes me begin to lean toward it.
--

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

   http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--