User:Zero Linden/Office Hours/2007 Nov 27

From Second Life Wiki

Second Life Wiki > Zero Linden/Office Hours/2007 Nov 27
Jump to: navigation, search
Zero Linden: As I always am, VL!
Vicero Lambert: lol
Malburns Writer: Hi Tao
Kooky Jetaime: hmm 830.. I might actually start comming then hehehe..thats... 11:30 for me
Zero Linden: So - back to log in
Burhop Piccard: (my productivity went up 10% when they put a starbucks by my office)
Zero Linden: This is phase 1 here
Vicero Lambert: lol @ burhop
Zero Linden: My idea is that this runs as follows
Zero Linden: 1: viewer contacts service (well known DNS name based on domain of your avatar identity) with { first-name, last-name,
Zero Linden: credential (like password), and some indicator of level of service desired)
Zero Linden: }
Jarod Godel: like
Zero Linden: steps 2 and 3 here are internal and we won't be specing
Morgaine Dinova: Or any name ... that's subgrid dependent, some grids may have different av name policies.
Vicero Lambert:
Tao Takashi: this is all encoded in LLSD?
Jarod Godel: ok. so it's a "grid" identity. thanks.
Tao Takashi needs to check out the recently released libraries
Zero Linden: nono, like
Vicero Lambert: ahh
Zero Linden: or even login.agni,
Jarod Godel: ok
Zero Linden: We need to agree on how a viewer knows where to go - right now, it is baked into the viewer, though specifiable on the command line
Zero Linden: which is how you use the viewer with an OpenSim grid
Zero Linden: But user's won't know how to spec those things
Zha Ewry: Most users. will get one with a baked starting point, and never care
Zero Linden: Even us dev's don't and development versions of the viewer have the magic DNs names baked into the code
Zero Linden: for each of the development grids
Zero Linden: I don't know, Zha
Morgaine Dinova: Clients will provide ways of hiding the details from users, it's not an issue. The key point is that on each subgrid, you have a login URL and one or more login data.
Zero Linden: I think that most people will be using generic viewers, or one from LL
Jarod Godel: Zero, treat like like a cookie
Zero Linden: Do we need to standardize on that mapping - I think we might or we
Tao Takashi: viewer authors will come up with something I guess ;-)
Ahzzmandius Werribee: LL could provide a root level "agent domain" dns service. similar to root servers in DNS.
Zero Linden: are leaving a crucial, first piece of the user expereince out
Jarod Godel: maybe you start with the baked-in login, but the client should be able to cache others'
Tao Takashi: and somebody might do some web2.0 like directory service
Jarod Godel: and, no to mapping
Ahzzmandius Werribee: part of getting officially into the grid would be to get registered in that root server.
Zha Ewry: YOu want to make the default behave as easily as possible for 90% of the users.. and..
Zero Linden: I'm thinking like this: If I enter my user name as
Zero Linden: that might map to using services from
Zha Ewry: Note that it's not clear that it's anything but a how to build a client discussion
Tao Takashi: but is this login service not just the main entry point for one grid?
Jarod Godel: people/clients need to be able to transact over the web, with random scripts, not just with virtual worlds
Ahzzmandius Werribee: zero, that looks like a good plan at first blush.
Squirrel Wood: What about querying a server for a list of known services and let the user pick one instead of having to use the command line switches?
Jarod Godel: Wait...why are you re-inventing OpenID?
Morgaine Dinova: Zero: no, that sets a VERY bad precedent to use DNS domain name constraints for av naming.
Zero Linden: Tao - well, it is the first stage of login, and it is for establishing the connection to the agent domain that controls your agent
Rex Cronon: no zero. why not just add another textfield where the used can enter the url of the grid that it wants to connect to?
Zero Linden: Jarod - perhaps we arent'
Jarod Godel: It sounds like you are
Zero Linden: what if IS an OpenID
Jarod Godel: then DNS mapping doesn't matter
Zha Ewry: Do distinguish, tho.. between client design and protocol
Zha Ewry: So far.. this.. is client design
Zero Linden: and the document at that URL (or rather at the implied URL of )
Zero Linden: contains a meta tag pointer to the agent domain server name
Zero Linden: But Zha -
Zero Linden: it isn't, i think
Zha Ewry: The first place where it becomes protocl design.. is where I interpret what's at that point
Tao Takashi: so for each grid I might need a different login server
Zero Linden: because if we don't spec how you go from a name to that initial DNS name
Tao Takashi: not sure where the problem here is ;-) just look at the grid's homepage
Zero Linden: then users, who deal with names, will have a non-standard way of getting in
Zha Ewry: Ah.. the mapping, maybe
Tao Takashi: it might even be a link which autostarts the client with the right one.. of course phishing might be a problem them
Zero Linden: But, let's not get bogged down,
Zha Ewry: How the client manages it.. not so much
Morgaine Dinova: To use domain names like this is extremely bad, because it ties logins to domain name delegation.
Zero Linden: we can just not we may want to spec. or at least reccomend a common approach
Zero Linden: SO
Squirrel Wood: initial dns name... client could query server for known services, then let the user choose one?
Rex Cronon: why would u need a link to restart the client?
Zero Linden: Well, I'm not tremendously fond of mapping things into DNS - DNS has certain tuned properties
Zero Linden: and it doesn't work for general things like this
Zero Linden: BUT most OpenID setups do
Tao Takashi: maybe we can also postpone this discussion for now ;-) I'd think that first we should have a working login and then we can still finetune these details
Zero Linden: ANYWAY
Jarod Godel: I don't mind mapping to dns, but I don't think this needs to be mapped past "
Zero Linden: so - the response to 1
Zero Linden: which, if you notice, is MUCH simpler than current login
Zero Linden: is a single capability (or perhaps a set of capabilites, only one of which is required)
Zero Linden: the required cap is the "seed-cap" for the agent domain
Morgaine Dinova: Tao: the trouble is if login is tied to the structure of domain names now, you can't "fine tune" that out later.
Zero Linden: It is the way the client initiaites #4
Tao Takashi: Morgaine: I didn't mean to wait after the first release
Tao Takashi: but after some prototype
Tao Takashi: or at least after this meeting ;-)
Ahzzmandius Werribee: morgaine, that's why I think a dns-like lookup system would be good to provide pointers tot he apropriate servers for each type of task in each user's domain.
Tao Takashi: it might also depend on how this protocol is used
Morgaine Dinova: Ahzz: I agree there ... just not that the account names should appear in DNS.
Zero Linden: In number 4, you invoked the seed-cap with a list of other caps you want: { caps-wanted: [ 'inventory', 'region-tp', 'im', ...] }
Zero Linden: and the response to that is the list of granted (or denied) capabilities
Ahzzmandius Werribee: Morgaine, that's decideable later in data specific choices. :-)
Zero Linden: Morgain - let's put that part of the protocol in a discussion page for now
Jarod Godel: That I think should be DNS mapped
Morgaine Dinova: kk
Ahzzmandius Werribee shuts up. :-)
Tao Takashi: so how is the call for getting the other caps?
Zero Linden: So - is this section clear?
Burhop Piccard: This is good, Zero.
Zero Linden: In style, at least
Zero Linden: I think one note
Ahzzmandius Werribee nods.
Rex Cronon: which section
Tao Takashi: could you simply do a GET http://host/<seedcap>/capabilities/inventory ?
Rex Cronon: ?
Tao Takashi: I guess you want to group that into one request
Zero Linden: for now we could / should have a cap called 'legacy-login' - which would return a URL to something that would mostly be the old log-in service (minus the authentication section)
Morgaine Dinova: Tao: no, just the opposite: some LCC clients don't want all that overhead.
Zero Linden: this would be the fastest way to get this coded and running
Tao Takashi: well, I agree for that overhead part
Zero Linden: Tao
Tao Takashi: just wanted to know a little how these URLs might look like :)
Jarod Godel: Tao, I assume "host" there is the sim, not the asset server
Zero Linden: Ah, well, at present
Zero Linden: no
Ahzzmandius Werribee: tao, technical details TBD later.
Tao Takashi: it's not the sim
Tao Takashi: we are not yet at the sim level
Zero Linden: becuase we've found in practice that it is far better to IGNORE everything after the cap in the URL of a request
Zero Linden: in otherwords, ifyou want a cap
Zero Linden: to support multiple functions
Tao Takashi: ah, interesting
Zero Linden: then you encode what function you want in the body of the request
Tao Takashi: so why is this better?
Zero Linden: The reason is this:
Jarod Godel: (Oh, I thought I saw Zero say "object" somewhere. Sorry.)
Zero Linden: The way a cap gets granted is that something decides that the viewer should access to some function
Tao Takashi: host is something in the agent domain, probably your agent host
Gigs Taggart: is that really restful?
Gigs Taggart: you no longer identify the asset by the url then
Zero Linden: it represents that function as an internally accessible URL
Morgaine Dinova: In general, coupling things together is bad, as it hardwires policy. However, if the "legacy-login" is just an optimization (equiv to asking for lots of caps separately), then fine.
Zero Linden: like:
Tao Takashi: so you then call another URL internally?
Zero Linden: or http://localhost:12036/map/layer-data
Zero Linden: Then it asks the capability system to grant a cap to this
Zha Ewry: Ahm Zero.. as soon as you start posting function into the body.. aren't you gettign away from the big 4 rest verbs and drifting towards SOAPy things?
Zero Linden: the cap systems generates a random cap to itself, like http://localhost:12040/cap/abcde09876
Tao Takashi: ok, so it's basically tinyurl with longer URLs ;-)
Zero Linden: and internally associates it with the internall
Zero Linden: YES - exactly
Tao Takashi: so how would this work for inventory then later on?
Tao Takashi: say I want to access object with ID 443
Zero Linden: Zha - somethings, like granting a cap, are pretty functiony, or POST like
Tao Takashi: I guess I don't need a cap for every object?
Zero Linden: just to close the loop here
Zha Ewry: God, I hope we need a cap per asset server, at best
Zero Linden: so when the viewer invokes http://localhost:12040/cap/abcde09876
Neas Bade: perhaps an example of what the function in the body would be would help
Zero Linden: the cap server just looks up to see if there is any associated internal URL
Tao Takashi: so the cap server is a proxy then?
Zero Linden: and if so, just proxy's the request
Zero Linden: YES
Saijanai Kuhn: right now its just an array of keys
Zero Linden: Indeed - it is verysimple code - which is nice for something that is central t the security of the system
Tao Takashi: not sure I'd rather would like a cap per "module" not per function
Zero Linden: So, let's take the inventory item request
Zero Linden: example
Zero Linden: The viewer wants information about inveotyr item 443
Zero Linden: we'll assume it has a capability to the inventory system, say http://{inv-cap}
Zero Linden: There are three ways one could design this:
Tao Takashi: so capabilities are always complete URLs I assume
Zero Linden: let the viewer invoke GET on http://{inv-cap}/item/443
Saijanai Kuhn: https://url:port/cap/UUID
Saijanai Kuhn: so youre going with http now?
Zero Linden: let the viewer POST to http://{inv-cap} with a body of something like { verb: get-item, item: 443 }
Zero Linden: oh -sorry - ALL CAPS ARE HTTPS
Zero Linden: (caps intentional)
Zero Linden: :-)
Goldie Katsu sighs in relief
Zha Ewry: Have to be, or it is Man in the middle vulnerable
Zero Linden: And lord knows we want to stick it to the Man!
Tao Takashi likes GET more
Zero Linden: he he
Zha Ewry: Or at least keep the Man out of the middle
Tao Takashi: more natural IMHO
Zero Linden: Okay, so, the thrid way is a bit subtle:
Zero Linden: POST to http://{inv-cap} with a body of { item: 443 }
Goldie Katsu: just one question (which I probably should have asked a while ago) is there a way that the client knows the cap server is legit and not an imposter?
Zero Linden: and have that return a cap just to item 443: https://{cap-inv-443}
Zero Linden: NOW we can do REST on THAT cap doing GET and PUT and DELETE etc
Ahzzmandius Werribee: Goldie SSL certificate chain
Tao Takashi: but you have 2 requests all the time
Zero Linden: Goldie - it has to do with that initial log in - it has to be over HTTPS too, and
Zha Ewry: Right.. but.. that's expensive, having a cap per item we touch
Neas Bade: um, why would you do item 3
Zero Linden: the viewer better check the certs
Goldie Katsu: ok...and the client id is validated how?
Tao Takashi: maybe for putting an object
Goldie Katsu: (Do we have bidirecitonal verification or can I spoof your client?)
Tao Takashi: for PUT you might eventually first get a URL anyway
Zero Linden: Right now, in the current SL viewer - the login servers have SSL certs traceable to a Root CA
Neas Bade: it really seems like you break a lot of the natural flow by not going with approach 1
Tao Takashi: I am definitely for option 1
Tao Takashi: as we do GET something
Neas Bade: agreed
Zero Linden: and the capability servers have a SSL cert traceable to a CA whos cert is in the viewer and the viewer insists matches
Ahzzmandius Werribee: option 1 also seems more apropriate to me.
Zero Linden: So - we are all agreed that option 2 is poor
Ahzzmandius Werribee: yep
Zero Linden: Good - internally, over tha last year
Tao Takashi: I don't see the benefit with 2
Neas Bade: yes, option 2 is poor and confusing
Zero Linden: we've been between 1 and 3
Zha Ewry: 1 is slightly soapish.. but simple
Tao Takashi: I am all for simple ;-)
Zha Ewry is trying very hard to avoid soapish
Zero Linden: we always thought we'd do 1, but we kep't getting by with 3
Tao Takashi: 3 might get expensive
Zha Ewry: Parsing headers it expensive
Zero Linden: Now, 3 is the classic capability paradigm
Zero Linden: The pure caps folks wouldn't dreamof any other way
Zha Ewry: Verbs in headers.. even good ones.. is no really REST
Neas Bade: Zha: why do you think option 1 is soapy?
Zero Linden: because in 1, you offer a single cap, and it supports a huge set of functionality
Zero Linden: of course, practically, we recognize it is all a continuum:
Zha Ewry: Not quite so much soapy.. as less RESTy
Zero Linden: most systems on the internet to day, your session cookie is a single capability giving you ALL access
Tao Takashi: why is it less RESTy then? :)
Saijanai Kuhn: 1 seems worth doing for a CAP that returns [possibly] multiple caps. The seed-cap and the like
Zha Ewry: As soon as the verb isn't one of the big four.. but.. an operation.. and the asset.. is not mewrely get/put/post/delete It get nervous making
Tao Takashi: but isn't the verb GET here?
Zero Linden: Where as a capability to post a comment (say) is still a cpaability of a range of different operations - like posting "I like it" vs. posting "yuck"
Neas Bade: yeh. I'm confused by your comments zha
Tao Takashi: maybe you mean #2?
Saijanai Kuhn: so its https://{CAP} POST key1, key2, key3, etc
Zero Linden: in other words if the function takes arguemnts, it is always a range of cuntionality
Saijanai Kuhn: and you get back the standard dictionary as you oo know of key1=CAP1, etc
Morgaine Dinova: Sai has copyright on that word
Zero Linden: So, back to 3 vs. 1
Neas Bade: right, but one of the key differences is that GET https://{cap-url}/item/431 is fundamentally cachable by url
Zero Linden: The problem with 1 is one of security
Zero Linden: it was really easy to simple substitute the internal URL during the proxy
Day Oh: But wait, aren't there types of data that can't go in a URI
Zero Linden: whereas, picking off the variable part of the invoking URL and tacking that on to the end of the matched internal URL
Zha Ewry: GET is.. but
Zero Linden: was full of pitfalls
Zha Ewry: Are we still pulling open the header to konw what we are doing?
Zha Ewry: REST reissts that
Tao Takashi: I would actually simply map that rest of the URL to my object tree
Zero Linden: consider https://{inv-cap}/../../money/add-funds
Tao Takashi: (should I do it with Zope)
Zero Linden: see,you have to very carefully sanitize the path fragments
Zero Linden: and the there are arguemtns
Zero Linden: whereas, if you make a clean substitution here - internal for external -
Zero Linden: THEN, the internal service has a clear security policy:
Zero Linden: "trust everything in the URL, as it game from the original capability grantor; trust nothing in the body as it game from the invoker"
Zha Ewry nods
Ahzzmandius Werribee: zero, good point.
Zha Ewry: Also.. the URL is easy to redirect on. without parsing the whole message
Tao Takashi: good point but IMHO still expensive ;-)
Zha Ewry: The body.. you have to open up the XML genie
Zero Linden: So now, during say upload, the sim can grant a cap to the internal URL: http://localhost:12035/asset/upload/script?agent=xxxx&item=yyy
Zero Linden: and the code at /asset/upload/script
Neas Bade: that still smells funny to me
Zero Linden: can trust with certainty who this upload is for
Tao Takashi: looks not that RESTy internally ;-)
Zero Linden: well - no, it is still a PUT (in this case) all the way: PUT from the viewer to the cap, proxy'd to a PUT to that internal URL
Tao Takashi: but it could be /user/<agent>/inventory/<pathtoscript>/<item> (via PUT)
Saijanai Kuhn: Would it be possible to have paths be abreviations to collections of services?
Zero Linden: Actually, REST always allows the function at the end of the URL to use the path of the URL as a function input
Neas Bade: wait a sec. the ../ stuff is just server parsed. There is no reason that .. in a url means go up
Zero Linden: and REST, or HTTP, doesn't care a wit if it is in the path or the query args
Zero Linden: Neas - well yes and no
Tao Takashi: I thought that was one of the ideas but I still need to look into the REST details
Neas Bade: the money counter example bothers me as a bigger fundamental issue
Zero Linden: yes it does, but
Neas Bade: "trust the url" seems like a bad design point
Zero Linden: acutally, the URI spec DOES give meaning to .. in the context of URI schems that are path based
Neas Bade: I think it will lead to trouble
Zero Linden: AND most server frameworks will interpret it
Zero Linden: since the caps system doesn't want to make assumptions about the system implementing the internal URLs,
Zero Linden: it would have to be aware and filter such thigns
Tao Takashi: if I'd do that in Zope and we get a .. it would actually go up but security checks will still kick in and the cap object in the middle might prevent going further up
Tao Takashi: but it would mean that you have additional checks in there
Zha Ewry: Ouch. .. is evil
Zero Linden: well sure, But we want to make sure, at least here in LL, that using off the shelf things like Apache is easy to do
Zero Linden: SO - no ..
Tao Takashi: which not every system has or wants to implement
Neas Bade: a straight up reject of urls with .. would be better
Neas Bade: which you could do with a mod_rewrite rule very easily
Zero Linden: it is even more evil, Zha, when you look at the the spec says about things like and
Tao Takashi: you can also prevent in apache to go further up with mod_rewrite I'd guess ;-)
Zero Linden: Neas - and then ther eis the whole issue of safely merging query args....
Zero Linden: So - for the first caps server at LL, a year ago, we just said "eh, later...."
Zero Linden: and have been happily working with style 3 caps for a very long time
Zero Linden: so far, it has been just fine
Zha Ewry: It takes you places. which are relaly bad, Zero. I've looked at that.. and a few other notations.. and.. because they aren't widely used.
Zha Ewry: How much do you want to bet many of them are handled wrong in various tools?
Zero Linden: Zha - oh, I'm sure they are!
Zero Linden: As for caps and REST
Zero Linden: here is the crux of the issue
Zero Linden: REST explictly says that there is no inherit relation between and
Zero Linden: they are just two different resource names,
Zero Linden: In general, you want a CAP to represent a bounded, set of functionality
Zha Ewry: Right. Not allowed to assume containment
Zero Linden: So, if a single CAP, say {inv-cap} is to offer access to two or more inventory items
Tao Takashi: REST might say that but humans might think otherwise ;-)
Zero Linden: there isn't really a REST argument to say that https://{inv-cap}/443 and https://{inv-cap}/981
Zero Linden: is better than POST to https:{inv-cap} with { item: 443 }
Neas Bade: actually, not true
Zha Ewry sighs
Zha Ewry: The lack of containment.. in REST.. is to avoid.. a bunch of twisty assumptions
Zha Ewry: But.. In this case.. wow. does it get in the way
Neas Bade: because I can much more easily build a spreader around the url path
Zero Linden: and having that return a CAP that you can then GET/PUT/POST to
Ahzzmandius Werribee: it's starting to sound like using data within the URL is something that we want to avoid. 8-(
Zero Linden: Neas - in so far as you only have one axis to "drill down on" and so it can be made more generic?
Tao Takashi: so according to wikipedia POST stands for Create in CRUD
Tao Takashi: is this wrong?
Vicero Lambert thinks going back tp punchcards would be good :)
Vicero Lambert: -to
Wyn Galbraith has some of those somewhere, unused.
Zero Linden: Tao - refernece?
Zero Linden: I don't know what CRUD is (well, other than my old code when I look at it a year later...)
Tao Takashi:
Tao Takashi: Create, Retrieve, Update, Delete
Tao Takashi: or Read I guess
Tao Takashi: the 4 basic db operations
Zero Linden: ah - that page says that it is often "compared with CRUD", not that it is defined by CRUD
Zero Linden: and no, I think the comparison, especially with respect to POST, is poor
Tao Takashi: maybe I should read Roy's chapter on it
Zero Linden: Indeed
Zero Linden: I should too
Tao Takashi: but for now for me it gets more and more blurry what REST actually is and why it is good ;-)
Zero Linden: Maybe we should get Roy to contribute or at least come to one of these!
Neas Bade: the O'Reilly book on REST is *very* good
Zero Linden ponders that
Zha Ewry: The basic things about rest are that it works well, with cache
Tao Takashi: except it adds a lot to our discussion :)
Neas Bade: it just came out in May
Zha Ewry: and with scale out, in general.
Zero Linden: you mean "RESTful services"
Sammy Grigges: hi guys
Zero Linden: ?
Tao Takashi: that POST would not work that good with a cache
Zero Linden: okay - well, it is now 2pm
Neas Bade: zero, yeh
Zero Linden: and I've got to go
Ahzzmandius Werribee: :-)
Zero Linden: Neas - yes it is very nice
Vicero Lambert: kk ttyl zero
Neas Bade: it concerns me quite a bit that an asset get is doing to get done with a POST
Wyn Galbraith: Thanks Zero.
Zero Linden: I'm going to take this discussion as mandate that the capabilities page should be the next one for me to flush out
Tao Takashi: Neas: I guess you need to forget all your implied meanings into those verbs ;-)
Wyn Galbraith has lots to think about.
Malburns Writer: tks zero
Zero Linden: and we'll get to login on Thursday
Rex Cronon: bye zero
Tao Takashi: thanks Zero
Personal tools