[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]