Re: [security-services] Attribute values in metadata (redux)

["Eve L. Maler" <Eve.Maler@Sun.COM>]

A long time ago we had discussed "attribute query enhancements" that 
involved specific attribute values; I don't think we want to go there in 
the actual query protocol at this point, but perhaps it's cheap to do it 
in the metadata for the reasons you mention.

	Eve

Scott Cantor wrote:

> I brought this suggestion up earlier, but it didn't get a favorable
> reaction. I'm bringing it up again because it's looking like a problem for
> our use cases to not have this feature, so I'll try and explain it better.
> 
> What we want to do is use the <AttributeConsumerService> metadata element to
> publish information about services so that we can develop tools for
> administrators to use in establishing policies about the release of
> attributes to particular service providers. As part of this, I made the
> metadata capable of documenting sets of attributes that are either required
> or optional for accessing/using particular services. It's not exactly access
> policy, although it relates, obviously.
> 
> So far, so good. The problem comes in when you have certain kinds of
> attributes where the attribute name is not in and of itself a useful
> discriminator because the value space of the attribute is potentially large
> and varied, and applies to many different services. I'll use an abstract
> example. Imagine an attribute named "role". This could include many
> different kinds of roles, and some roles might only apply to some services.
> So my service is not just interested in "role", but more specifically in
> "role" with value "HR Officer" or value "Finance Officer". Any other role
> values are irrelevant to my service, so I have no interest in them.
> 
> A concrete example of this is an attribute in the eduPerson spec called
> eduPersonEntitlement, which is a way of capturing permissions to access
> particular services in a person's LDAP entry. To avoid the explosion of LDAP
> attributes that would occur otherwise, we store potentially many different
> permission URI values into this single attribute, but a given service
> probably only cares about (and should receive) a few or even one value.
> 
> So what we're asking for is the ability to include AttributeValue elements
> inside the metadata to better drive the establishment of these policies. In
> concrete terms, it would be changing the base type of the
> <RequestedAttribute> element to AttributeType instead of
> AttributeDesignatorType.
> 
> There are no strong processing rules here, because this is metadata, not
> protocol changes.
> 
> Now, obviously one can imagine changing AttributeQuery to also support such
> a feature, and that's probably useful, but it opens the door to more
> complexity than putting it in metadata does, which is why I'm starting with
> the simpler end.
> 
> -- Scott
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave_workgroup.php.
> 
> 

-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Products, Technologies, and Standards    eve.maler @ sun.com