OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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

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]