[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Attribute values in metadata (redux)
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]