|
Steve, What
Santosh said. Overloading the
attribute value OID with policy information seems like a messy solution to me
that will not scale well. Furthermore,
it is conceivable that applications may want to take different actions when
they don’t understand the syntax of a particular attribute vs. when they don’t
find the policy under which it was issued acceptable. Using the attribute value OID to convey policy information
makes it impossible to make this distinction. Chris -----Original
Message----- Steve: Let us assume that there
are n attributes and m policies. Chris's approach will
require you to register n + m OIDs and an application will have to know about
no more than n + m OIDs. The other approach will
require you to register n * m OIDs and an application may have to
know about up to n * m OIDs Thus, the second approach
makes the OIDS proliferation faster. How fast, depends on n and m. -----Original Message----- At 3:11 PM -0500 12/23/02, Chris @ work
wrote: Steve, I considered
that approach initially, but rejected it becuase it inhibits
interoperability. If issuers have to define a unique OID for an
attribute type to reflect their particular policy, then this makes it difficult
for AC processing software to be developed to support a common set of
attribute types (such as those defined in RFC-3281 for instance). Chris Chris, I would have expected software that makes
use of ACs to have the OIDs for acceptable policies (and meaningful attributes)
specified as parameters to the software, so I'm not sure why using different
OIDs to represent attributes asserted under different policies would be
problematic. can you explain in more detail? Steve |