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