Re: [regrep-security] ebRIM 2.34-1 distribution (with XACML basedAccess Control Model)

[Nikola <nikola.stojanovic@acm.org>]

<Farrukh>
Please focus your review to chapter 13 of ebRIM 2.34-1 and send your
comments ASAP to this thread.
</Farrukh>

Here are my comments:

Generic:

- Do we need to say anything about SAML?

- RegistryObject class has been changed so sections 7.5.1 and 7.5.2 need to
be modified to reflect this.

- RepositoryItem class (Line 1662) has been proposed. I don't see a clear
Use Case that justify this (if assigning CACP to a repositoryItem that is
different then CACP for the corresponding ExtrinsicObject is the Use Case, I
still can't see the real importance of it). Introducing RepositoryItem class
has also implications that go far beyond Security and we need to investigate
what they are.


Specific:

- Line 1650: predicate is not defined (define it).

- Line 1665: We need to explain what these actions map to, like: what does
it mean (is it possible?) to create RepositoryItem, what is read of a
RepositoryItem, ...

- Line 1665: Should we include other registry actions beyond CRUD? If not,
then we might want to say that registry MAY implement other actions beyond
these.

- Line 1682: Descriptions for different Subjects seem to be wrong (need to
be changed).

- Line 1722: Change title of the figure so that it is clear that this is an
instance of the abstract model

- Line 1734: Remove prefix ebrim. from the slot name

- Line 1746: Do we need to define / explain how to bind registry Request /
Response to XACML Request / Response? This might be related to question
about SAML above. Also, how far into XACML binding we want to go in the
spec. If XACML binding is normative and required it seems to me that spec
need to go into more details. Picture and / or translation table that
illustrate / explain relationship between Registry semantics and XACML
semantics would be useful as well.


Regards,
Nikola