OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]