- From: -=jack=- <jack@twaxx.twaxx.com>
- Date: Thu, 1 May 1997 15:12:25 -0700 (PDT)
- To: Jon Radoff <jradoff@novalink.com>
- cc: "Ron Daniel, Jr." <rdaniel@lanl.gov>, w3c-dist-auth@w3.org
> 1. Define an API which would exist in a shared-library type space on > the server (or a DLL on NT). > > 2. Applications that wanted to be able to verify if a user has a > certain permission would make API calls to do so and respond > accordingly. > > 3. The shared-library containing API calls would be able to connect > to compliant modules defined by the system administrator (e.g., > if vendor X wanted to provide a module that makes them > compatible with the API, they'd ship this as a component -- not > unlike how ODBC works in the database world...) ------------------------- This is pretty nice, that's a good approach, IMHO, and ODBC has been a fairly successful endeavor, so that also bodes well. > 4. A basic concept of the API is to abstract the concept of > authentication and let the application worry about this (it > may be that we want to think of an interface specification for > authentication data too, but it wasn't part of my original idea). > We should discuss the pros/cons of this. --------------------- By authentication data, you mean a digital signature or some such ilk? Would you clarify this? Thanks... > 5. The API attempts to give the concepts around security a > "real-world" feel. Users own abstract, named permission > entities as opposed to traditional read/write/execute > permissions. That way, applications and security management > systems are free to define what a given named permission > entity means. ---------------------- Again, would you please clarify what you mean by "permission entities"? I would just like to have a clear definition of terms. > Other items for discussion: > > a. We should discuss whether it makes sense to include in any > standard the ability to define new permission entities; I was > leaning against this because I thought if we didn't keep it > abstract it could limit the creativity of what the "permission > server" vendors. --------------------- That's good, but let's just be clear on what even the `abstract' definition of these terms are just so we're all on the same page. > b. Should the abilty to assign permission entities to a content > object be standards defined, or application defined? I think > we probably need a combination of (i) basic permissions which > would exist in every DAV-compliant application and > (ii) the ability for applications to form their own rules > based on permission entities they could provide. ---------------------------- I like the combination approach. > What about > permissions on an object that are more granular than overall > access to the URI (such as a piece of a particular page?) ------------------------------ The same approach *should* be doable with a finer level of granularity for sub-pages, although consistent means of ID'ing the sub parts of pages is necessary [i.e. being able to parse with the ability to be sure everyone is parsing the same docs the same way]. > c. Does this track make sense at all? ;) -------------------------- Absolutely! -=jack=- (This text composed by voice)
Received on Thursday, 1 May 1997 18:11:08 UTC