[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] (local) names and issuer as string issue
Frank, I suggested that names be local, but need not be componentized, such as you suggest Polar's Hal's Tim. This naming form is of the work done by Lampson, et al in SDSI (Sudzi). This name has another unambiguous form of "Polar!Hal!Tim". However, they make one important distinction. Where there must be a trust point that is standard for names, and then there are mappings from those names. Such as DNS!!com!sun!east!anne.anderson However, such a name must be verified by the mapping using keys and signatures, etc, and it still is up to the particular mapping for the application. (It obviously works well for SDSI certificates, but for example, not well for X500 names). I would like to avoid all of that unwieldy complexity in XACML, and put it somewhere else. The attributes must be verified by signatures or some other means and their values must be put into a form that is understandable by the policy writer, from whatever technology was used. So, there is an established agreement outside the scope of XACML of the format and potential instantaces of those values and their datatypes. I don't see why we cannot do the same for names. Keep the issuer names simple strings, leave the mapping from the various naming technologies as an outside understanding between the policy writer and the input provider. That approach leaves out the complications. We can start a separate object or service that converts attributes of different technologies and specifies different mappings to local names in a separate component, keeping that mess, bowl of worms, barrel of monkeys, out of XACML. XACML is already pretty complex. Cheers, -Polar On Thu, 11 Sep 2003, Frank Siebenlist wrote: > 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. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]