RE: Summary of KMIP Entity Discussion 1/20/2011

[<Bob.Nixon@Emulex.Com>]

I have been mulling over an implication of this sentence in Alan's summary of an earlier discussion of Entity objects:

	"We decided not to restrict the number of subjects of a given type per Entity."

I'm guessing this translated into the "may be repeated" characteristic of the Credential object within an Entity, and formalizes the commonplace situation that most of us entities have lots of credentials. For example, I probably have anywhere between 50 and 100 different name/password credentials, which I keep in my own nonstandard credential server (an only lightly encrypted directory).

However, each of my passwords is of limited scope of validity: I have no chance of authenticating to Amazon.com with my OASIS KMIP password, for example. 

In KMIP 1.0, the scope of validity of a Credential was unambiguous by context: it is used only for validation with the Key Server, never for any other purpose. In our new work, one of the desired uses for an Entity is to "Register or generate data that can be used during authentication, possibly to a third party system". This seems to open the possibility that different credentials for the same entity may not all be valid for authenticating to all possible systems.  

The scope of validity seems to be a highly important "Locate" criterion for the new Credential: the subject name by itself is not in general sufficient. Again with the commonplace example, I can locate all the passwords for entity Bob Nixon (well, most of them), but if I could not also locate the specific one for Amazon.com, I would have to exhaustively try my whole list at any login. That would be absurd (and unrewarding, of course: most of my accounts have a "strike three, you're out" policy).

Would it be within the scope and interests of this group to augment the Credential specification with an optional "scope of validity" attribute? 

   -bob


-----Original Message-----
From: Frindell, Alan [mailto:Alan.Frindell@safenet-inc.com] 
Sent: Thursday, January 20, 2011 10:19 AM
To: kmip@lists.oasis-open.org
Subject: [kmip] Summary of KMIP Entity Discussion 1/20/2011

All, I've summarized our discussion from today.  Please post any feedback on the reflector this week and I will incorporate that into a proposal draft before the face to face.

Thanks

-Alan

We discussed the two different credential options, one that is a bit clunky yet backwards compatible, and another that is simpler but incompatible.  Tim asked that we discuss protocol versioning in greater depth at the face to face.  Hal pointed out that because the difference is largely one of format rather than semantics, it should not be difficult for a v2 server or client to support both formats.  I will draft the proposal with the simpler format pending the versioning discussion at the face to face.

Hal and I are still working through all the possible enumerations for authentication.  I will try to wrap this discussion up by next week.  The draft proposal should have both the enumerations and a description of how the client/server should interpret the 'Value' parts of the structure for the defined enums.

I will not include Archive Date and the associated operations for Entity.  I will include Object Group.  I'm looking for feedback on how to handle the two different kinds of operation policies for Entities - specifically do we need a new attribute, or can we re-use an existing attribute?

I will update the Default Operation Policy for Entity Objects to not include owner/creator references, but instead refer to the entity itself.  For example, by default, an Entity may only perform Get, Modify or Delete on its own Entity record.

The group felt it was OK to exclude Entity Registration from the Default Entity Operation Policy.

I think there was a consensus to use the Entity UUID as the Creator or Owner, but I will leave this for the Access Control proposal.

We decided not to restrict the number of subjects of a given type per Entity.  This may make for some odd edge cases, but should be sufficient for the common use cases and prevents us from having to solve complex questions like 'What is a user'.


The information contained in this electronic mail transmission 
may be privileged and confidential, and therefore, protected 
from disclosure. If you have received this communication in 
error, please notify us immediately by replying to this 
message and deleting it from your computer without copying 
or disclosing it.




---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php