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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: (local) names and issuer as string issue


In my (ever) continuing effort to find reasons to change the attribute issuer as 
string, I came up with an other argument:

As we don't put any restriction on the attributes values, they can be "local" 
names, meaning, they are not required to be globally unique and that all is left 
to the issuer.

This implies that for example, "frank" could bind a name "tim" to a key and 
"hal" could bind the same name "tim" to possibly an other key, and this would 
not imply that both frank and hal are referring to the same tim...
In the targets and rules, you can do the matching on both the name and the 
issuer to get rid of the ambiguity, which is essentially including the issuer 
with the name, like "frank's tim" and "hal's tim"

However, if we take this one level further, then "hal's tim" may not be the same 
as "hal's tim", because "hal" may not be "hal" .... ;-)
We can for example have a different "hal" in "polar's hal's tim" and "ann's 
hal's tim", and our current attribute scheme won't be able to distinguish them.

One could argue, that we could do the attribute binding validation before we 
enter the xacml evaluation world, but I don't believe that works for local name 
bindings: one can not see from the name assertion itself whether it is valid or 
not as its proper use is only in context, i.e. if there are 
xacml-rules/conditions that explicitly use that "issuer's name".

The recursion of these nested name bindings is stopped by an issuer with a 
'secure name'. The latter is a name with has implicit trust and is unique within 
the context, like a bare public key, a kerberos principal@realm through a shared 
secret with that kdc, a path-validate X.500 DN through a configured trust root, 
or possibly through a local name-password database.

In a short discussion that brought this all up, Polar suggested that we should 
just use some string concatenation convention to include the assertion path in 
the name value, like "polar's hal's tim". This would leave the issuer value to 
hold a secure name.

My objection was that this string concatenation was not very elegant... but I 
believe that Polar doesn't have a very "elegant" impression of XML in general, 
so he wasn't impressed with my argument...;-)

In summary, if we allow local name bindings (which is a good thing, btw!), then 
we may need some additional facilities to unambiguously identify these names 
within the context of the rules.

Comments? Suggestions?

Regards, Frank.

-- 
Frank Siebenlist              franks@mcs.anl.gov
The Globus Project - Argonne National Laboratory



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]