[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [regrep] Security proposal pointer
Kathryn, Thanks for the detailed comments on actors and roles. A possibly a good analysis pattern or paradigm in thinking about the Registry is that of a public library (private library should be OK too but it has less security implications). BTW, describing these actors and roles were necessary because we could not find a similar table that covered registry functionality in RS. I am certain that we will be able to clarify and simplify the actors and roles by discussing this further. More detailed comments inlined below. Like to hear what you think. Cheers, -Suresh -----Original Message----- From: Breininger, Kathryn R [mailto:kathryn.r.breininger@boeing.com] Sent: Friday, October 19, 2001 11:01 AM To: Damodaran, Suresh; 'regrep@lists.oasis-open.org' Subject: RE: [regrep] Security proposal pointer Comments on the Security Proposal: I think there is still some overlap and possible confusion between the actors and their roles. For example, Registry Operator and Registry Administrator. The comments column states that these may be the same person. The function for Registry Operator says that they host the registry objects, which sounds like this is the person who is responsible for the registry/repository. The registry administrator has the administrative functions for security, but a registered user is authenticated by a Registry Operator. I would think the Registry Administrator would be the one who authenticates a user. Is it really necessary to have two separate actors - Operator and Administrator? How will you clearly define the difference in the roles and functions? I would recommend making this one actor and combine the functions. Then the authentication of the registered user makes more sense. <sd> I will differentiate these roles as follows: administration (which is the maintenance of the credentials to principals and policies) and verification (verification of the presented credentials) are two separate roles. In a library, administration is done usually by humans who take your name, address etc. and give you a library card. The verification is done usually by a machine (with minimal human assistance) that reads the card and checks out books. A Registry Operator is responsible for the "execution of registry services," whereas a Registry Administrator is responsible for maintaining the credentials and security policies. When somebody says "let me get it from the registry," it really means, "let me get it from the Registry Operator." Similarly, all lifecycle operations are supported by the Registry Operator, whereas creation and maintenance of Registry Clients (more on Registry Client below) as well as creating appropriate credentials is done by Registry Administrator. </sd> What is the difference between the Registry Guest and the Registry Reader? It looks like they both have read access only. Neither of them have contracts, neither of them can change the contents of the registry. The way the functions are presented, they appear to have the same roles. You need to either more clearly define what the differences are between these two, or make them one actor. <sd> Registry Guest has NO contract, whereas Registry Reader does. These are described in the "Function" column for these actors. </sd> Registry Publisher may be a bit confusing - the terms sound like this is someone who publishes the registry. I know this is not what you mean here! What about Registry Submitter? (also closer to the terms ISO 11179 uses)? Sounds more like the function - submits stuff to the registry. Also, is this actor meant to be an organization, as opposed to an individual person? A Submitting Organization (ISO 11179) is the organization that submits the object, and an individual, who may be a registered user or registry content owner, is the actor who is an individual from that organization and physically performs the function. <sd> I am fine with using the term Registry Submitter instead of Registry Publisher (possibly makes more sense). RS could be an organization or individual (for that matter, any of the actors could be an organization or individual - haven't made any distinction anywhere This looks like an issue to consider in the next round). There is a subtle detail that is relevant here. The Registry content may not always be generated by an individual of an RS. think of a library - those who donate the books did not write those books. The creator of the contents ("writers") could be individuals or organizations, or individuals within organizations (all are Registry Content Owners, as stated earlier, we haven't made the distinction between individuals and orgs in which they work yet.) </sd> Look a little closer at Registry Client - the two functions listed are registered user or registered guest, but under registry guest the function says there is no contract, so I assume a registry guest is not registered, which conflicts with what it says under registry client. And does Registry Client include Registry Reader, who is also a registered user? <sd> yes - a Registry Client can be a Registry Guest, Registry Reader, or Registered User. This actor is created for both convenience in discussions (don't have to spell out RG, RR and RU) and for possible use later in access control policies. We don't have an access control policy proposed yet for V2. There is a role hierarchy picture that I should have included with this document. I will include in the next version. </sd> It seems that if the actors and functions in this proposal are for V2, then that is what should be presented in the table (looking at notes). If some of the actors are for V3, bring them up at that time. <sd> I do believe understanding the actors and their roles would greatly clarify our discussions of the registry. I suspect, therefore, there is some benefit in including this table in RS. </sd> Line 229, section 7 issues, number 4: In the registry we have implemented at Boeing, each submission to the registry is considered a different version. For example, version 1 of a DTD was submitted in January 2001. In May 2001, the content owner updated the DTD, and submits the updated version to the registry. This must go into the registry with a new version number, and as a separate registry record. Then we have two separate registry records for each of the versions. Users using version 1 can continue to do so, and be assured that it has not been changed. <sd> Sounds like a neat idea. Is it already proposed for inclusion in the specs? Once again, thanks for the comments, and I really hope I have clarified why we have the actors and roles listed this way. </sd> -----Original Message----- From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com] Sent: Thursday, October 18, 2001 2:03 PM To: 'regrep@lists.oasis-open.org' Subject: [regrep] Security proposal pointer Per today's request, here is the pointer to the proposal. http://lists.oasis-open.org/archives/regrep/200110/msg00005.html Thanks, -Suresh ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC