RE: [higgins-dev] Higgins data model for attribute values

["Drummond Reed" <drummond.reed@xxxxxxxxxxxx>]

> > Jim wrote:
> > My memory is slowly returning to previous discussions now...  We
> > once came up with a completely different semantic.  A present value
> > of password with no value meant that we know the user has a
> > password, and we're willing to produce an attribute with no value so
> > that you may attempt to modify the password, but we're not going to
> > reveal the password value to you.  I suppose that could be handled
> > in other way (that attribute could have a value, but an exception is
> > thrown when one attempts to access it).
> >
> > In the face of access control, I wonder how meaningful any of these
> > statements really are.  Whether or not I can see an attribute on a
> > subject, or whether or not I can see any values only means I can't
> > see that data -- this could be due to access control, other policy,
> > or an actual absence of data.  If consumers need to differentiate,
> > then we probably need to invent some specific exceptions to throw
> > under various circumstances.  Of course, then people will ask for a
> > "don't disclose on error" kind of setting which will prevent the CP
> > from throwing such exceptions, and the consumer will be right back
> > in the same boat.
> 
> Mike wrote:
> For access control. In case where:,
>       a)    <Groups/>
> or)
>       b)    <Groups><Group>Test</Group></Groups>
> or
>       c)    no Groups attribute
> 
> and Policy is Allow Operation X on Resource Y if not in Test group.
> 
> I think "a" is clearly allowed, "b" is clearly disallowed, and "c" is not
> clear.

Great example. The OASIS XRI TC spent multiple weeks debated the "absent or
null problem", i.e., the difference between an XRDS document having an
optional element or attribute be absent vs. having the element or attribute
be present with no value. We finally solved the problem by edict in the spec
by declaring the two conditions equivalent.

But this is much more subtle and much more architecturally pervasive, as the
rule(s) need apply for all of IDAS.

For that very reason -- since the range of attribute types dealt with by the
Higgins data model is so potentially huge -- perhaps the best route is to
make this an explicit part of the Higgins data model, i.e., define an
Attribute metadata attribute ("AbsentValuePolicy"?) that explicitly states
the policy if an instance of the attribute has no value.

For instance, in Mike's example, if there an AbsentValuePolicy property on
the Groups attribute whose value was "empty", then the answer to Mike's "c"
condition above would be "clearly allowed".

=Drummond