Re: WEBDAV Security

>   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