OGSA Naming Teleconference - 15 November 2004 ============================================= * Participants Mark Morgan (UVa) Andrew Grimshaw (UVa) Alan Luniewski (IBM) Hiro Kishimoto (Fujitsu) Michael Behrens (R2AD, LLC) Bill Horn (IBM) Minutes: Mark Morgan * Agenda Bashing/Agenda - Approval of Minutes from previous 2 calls - Walk through discussion of name v. identity and properties of each. * Minutes Approval - Approval moved and seconded * December F2F - Chris Smith and Andrew Grimshaw have talked about EMS. Plan to discuss more at December F2F. * Discussion of Name v. identity. - Last time we got twisted around the notion of name v. identity. How are they different. What does it mean to be unique? Same? - For the time being, let's punt on the issues of authentication and security. - Attempted to discuss and define name and identity without using those words. What are the properties we want and how do we describe the concepts we want to talk about. - An attempt to define the middle layer of a three layer naming scheme. What we'll call an Abstract Name (AN). - AN refers to an interface or port type and possibly some state associated with it -- in computer science, a closure - What does it mean to refer to exactly one thing? Is this unique? # If I have a bit pattern (an AN) that I talk to, and I talk to it a second time, does it matter if I go to the same physical place? - Any message history against an AN does not change regardless of how many different physical endpoints become involved in this message conversation. In other words, if one client talks to an AN in one way and another talks to it in exactly the same way, both conversations should generate the same message history. - Can a service have more then one name? Can their be aliases? - Is aliasing useful at this level, or should it be in the higher level (human readable) or lower level (endpoint, resource handle). - What does "uniqueness" mean? Does an AN have to be unique. # If you don't have aliases, then having two ANs implies that you can tell that the two AN refer to the same service. - If ANs are unique, and if there are no aliases (each closure/endpoint entity has exactly one AN), then we have a notion of identity. - Identity is a handle and if I compare it to another identity, then I should be able to tell if they are the same or different things. - Alternative definition of identical -- Two things are NOT identical if there is some sequence of actions using the handles that produces a message history different from the same set of actions on the other handle. - Notion of a message history allows us to get more formal with our definition of identity. - If two things are different, but their message histories are the same, then the differences are irrelevant. - If we don't allow aliasing, it makes things easier. # If someone has an alias under the covers then really they have implemented two different services and we don't have to understand that. # If we need aliasing, then we do aliasing at the human readable level. - Immutable # Since it is unique in space and time, then it can't be changed. # If you have an AN, then that AN always refers to the same thing. This implies that it can't be changed. If I change the name, it's a different thing. * Binding - What about binding AN to more concrete reference. # I have an ID, how do I know who to use to resolve that AN? # What about authentication? -- Should notion of identity be related to notions of identity that people have in security systems around Authentication? -- Punt until Frank is on. * Local vs. Global Names - We shouldn't distinguish between the two -- all global # If I have a bit pattern which is an AN, then it should be globally unique. # We want to pass these things around to everyone. - We must guarantee uniqueness - Prevent impostors -- gets into Authentication and security which we are punting on for now. - Unique not only in space, but also in time. - There is always a way to turn a locally unique id into a globally unique one. # Doesn't mean you won't ever have local ids, but once you get to the level we are talking about, it should always be globally unique. * Format of an AN - Should it always have two parts (global, and local part) # We should be VERY flexible in how it is formed. # Perhaps something like a URI, but you don't really need to put a whole lot of semantics on it. # If someone has a web service at http://somemachine/some-service then they should be able to use that URL as their name. # Want to prevent people from looking at an AN and saying, "Ah, I can see from this name that this target resides at "somemachine". We don't want them interpreting the AN, just using it. * AN to EPR (Renewable Reference, whatever) Resolution - Something like OGSI GSH resolution - You have a resolver service where I can pass in an AN and possibly an EPR. The resolver gives back an EPR # You pass in the EPR so that if you have a binding that is bad, you can as the resolver for a new one and at the same time say, "Hey, this EPR I have isn't good, so don't return that one to me." - Can imagine encoding information about another resolving service into the AN so that you can terminate recursive resolutions. That way, clients can use any resolution service they want. # Gives clients a transparent view which is partially a cache. - Resolution gives back a binding (AN, EPR, timestamp, etc.). # Timestamp is a hint, not a guarantee. Might indicate how long you expect a binding to be good for, etc. - Must be efficient. - What about people who say, "Why not use DNS?" # Permits aliases which we don't want # Permits change (not unique in time) - Binding is not to a single Address necessarily, but could be to a list of addresses. Not that the addresses are the same. The only requirement is that the message histories of those addresses is the same. * Anything we should ask the web services world to provide? - Naming is one thing - State services * Registration of ANs - You almost have to register ANs. - Sooner or later their must be an authority on an AN. - The authority could be encoded in the AN. # Makes it a little immobile - How bindings get into the registration service is, to some extent, irrelevant - If I have a binding which is bad, how do I get a new one? - How do we determine if a binding is bad? This might be where Frank was getting to with his Assertions. * Factories - We need the notion of a factory badly. It's too hard to do a lot of things without this. - Once you have factories, the notions of registration become easier. Future Thoughts --------------- At some point, we need to get more concrete about what these names are, about security and authentication, etc. Action Items ------------ Andrew to write up naming as discussed as a proposal Discuss security aspects next in two weeks on the 29th of November.