[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

fwd: Re: ideas about the decision interface

John and I got into the same trap:)

Apparently messages addressed to "owner-hrac-rfp" get nowhere. Only messages
sent to "hrac-rfp" are received by the list.

Please see the attached messages.

Konstantin

-- BEGIN included message

John,

my comments are inline

> folks,
> 
> Some comments on the proposed interface.
> 
> >Resource space is defined as a flat one due to the lack of knowledge on
> >it. 
> 
> My understanding is that the resource space is flat only from the point of
> view of the interface. In reality, the resource space could have any
> dimensionality. A relational database is an example. The Access Decision
> Object (ADO) can be called with a Resource referring to a table and/or to a
> column in that table.

it's correct. The question is whether resource space should be structured (i.e.
be not flat). There are pros and cons on either side. For example, since the
RFP is healthcare specific and most of the resources in healthcare are
patient-centric, I can see a lot of sense to explicitly have resource space
structured so that patient ID, according to PIDS, can be obtained in a
standard/specified way.


> 
> >The code looks kind of too long for such simple data structures and the
> >computational model. It's mostly because of the way exceptions are
> structured
> >for inquiries on multiple <resource, operation> pairs.
> 
> I think that inquiries with multiple <resource, operation> pairs is useful
> feature. It provides an ADO client with the opportunity to use the ADO
> efficiently when the client has knowledge of resource structures, e.g.,
> when groups of resources have access control information co-located.
> 
> >   // Define Operation   typedef short Operation;
> >   const Operation CREATE = 0;
> >   const Operation READ  = 1;
> >   const Operation WRITE = 2;
> >   const Operation USE  = 3;
> >   const Operation DELETE  = 4;
> 
> I would think that the operation depends on the resource. If Resource is
> opaque, then Operation would be as well or at least, implementation
> defined. 

These are the operations the RFP is asked to specify at minimum. There is a way
to accommodate notion of opaque operations via operation family identifiers.
It's a similar idea to CORBASEC's Security::ExtensibleFamily approach. Then,
any application/authority can add their own set of operations. The only
limitation with such an approach is the fact that operation type should be some
IDL type, i.e. not just opaque.

> 
> >   // The operation is none of the defined above
> >   const OperationErrorCode BAD_OPERATION                = 0;
> >   // The operation is valid but is not supported by the facility
> >   const OperationErrorCode UNSUPPORTED_OPERATION        = 1;
> 
> I think you need an additional OperationErrorCode like "ACCESS_DENIED" for
> the multiple_actions_access_allowed() method.

What would be the meaning of this code?

> 
> >      short resource_error_code,
> >      short operation_error_code
> 
> Don't you want:
> 
>     ResourceErrorCode resource_error_code,
>     OperationErrorCode operation_error_code

yes. I'll change it.

Konstantin

-- END included message

-- BEGIN included message

folks,

Some comments on the proposed interface.

>Resource space is defined as a flat one due to the lack of knowledge on it.

My understanding is that the resource space is flat only from the point of
view of the interface. In reality, the resource space could have any
dimensionality. A relational database is an example. The Access Decision
Object (ADO) can be called with a Resource referring to a table and/or to a
column in that table.

>The code looks kind of too long for such simple data structures and the
>computational model. It's mostly because of the way exceptions are
structured
>for inquiries on multiple <resource, operation> pairs.

I think that inquiries with multiple <resource, operation> pairs is useful
feature. It provides an ADO client with the opportunity to use the ADO
efficiently when the client has knowledge of resource structures, e.g., when
groups of resources have access control information co-located.

>   // Define Operation   typedef short Operation;
>   const Operation CREATE = 0;
>   const Operation READ  = 1;
>   const Operation WRITE = 2;
>   const Operation USE  = 3;
>   const Operation DELETE  = 4;

I would think that the operation depends on the resource. If Resource is
opaque, then Operation would be as well or at least, implementation defined.

>   // The operation is none of the defined above
>   const OperationErrorCode BAD_OPERATION                = 0;
>   // The operation is valid but is not supported by the facility
>   const OperationErrorCode UNSUPPORTED_OPERATION        = 1;

I think you need an additional OperationErrorCode like "ACCESS_DENIED" for
the multiple_actions_access_allowed() method.

>      short resource_error_code,
>      short operation_error_code

Don't you want:

    ResourceErrorCode resource_error_code,
    OperationErrorCode operation_error_code

jb

-- END included message