[Jsdsi-devel] [Fwd: Re: Proposal]

[Sameer A. <aj...@cs...>]

-------- Original Message --------
Subject: Re: Proposal
From: "Sameer Ajmani" <aj...@cs...>
Date: Wed, February 11, 2004 5:07 pm
To: <sra...@ae...>

Comments inline:

> 1. Fixed a few bugs / added umimplemented features.
Cool -- which?.

> 2. Added a new Tag type (FilepathTag which is to specify a Principal's
> access rights to a file hierarchy)

Shouldn't this just be a combination of SimpleTags, SetTags, and
PrefixTags?  For example:
(file-access (*set read execute) (*prefix /home/ajmani))
would grant read and execute permision on any files under my home
directory.

> 3. A new concept on tags .sameAs() (wasn't happy about this, but at
> the time had to be done - would ideally like to get rid of it, but
> concensus may in the end be to keep it) - it allows tags of different
> classes to be compared as equal() in terms of functionality.

I think the new implies() method on Tags provides this behavior.  Tag A
implies() tag B if tag A grants all permissions granted by tag B (and
possibly more).  For example, the file-access tag above implies() these
tags:
(file-access read (*prefix /home/ajmani))
(file-access execute (*prefix /home/ajmani))
(file-access (*set read execute) (*prefix /home/ajmani/bin))
(file-access execute /home/ajmani/bin/script1)

If tag A and tag B implies() each other, they should be equals().  See
TagTest for many more examples.

Note that the Prover may now return certificate chains that create a tag
that's stronger than the one requested.  This makes JSDSI much more
flexible -- you no longer need to match your request exactly to the tag
returned by the Prover.

> 2. Generated the idea of a Question to pass to a Prover or Searcher
> for retrieving a Proof or collection of certificate chains meeting
> some criteria.

Does the new Prover behavior described above obviate the need for the
Question class?  How is Question different from CertPathParameters?

> 3. Created some rough and ready implementations of a distributed
> Prover and Searcher for processing Questions.

Interesting -- how does this work?  I designed the Prover to work well
when fetching certificates from a remote CertStore, but it sounds like
you've actually distribuetd the Prover itself.  This definitely sound
slike a cool addition.

> 5. A class to detect circular questions.
Like "Does Alice grant read access to Alice"?

> 6. A Pipeline to configure provers/searchers/caches into a
> process-flow. (probably a few other bits and pieces...)
Definitely cool -- perhaps what we want is a jsdsi.process package...

> In addition I've Maven'ised both JSDSI and my mini-project.
Hmm.  I still use old-fashioned Makefiles, but useing something more
advanced is probably smart :)  I just hesitate to make people download
yet-another-package to use JSDSI.  Overall, JSDSI needs much better
documentation, and at least a HOWTO or Getting Started guide.

> Sorry, I hadn't realised that you had made a new release. Are you
> planning to start versioning the releases and announce them along with
> intended future plans?

I really should.  We haven't been using the jsdsi-devel, jsdsi-users, or
jsdsi-announce lists provided by SourceForge, and we ought to.

> As regards to my suggesting of a change of name. This is because I
> feel that JSDSI is an implementation of SPKI 2 and as such should
> reflect this and anyone doing a cursory search for SPKI information
> may miss out on this valuable library. - just my view (it's all about
> marketing) However, I totally understand your respect to legacy users.

Well, the title of the JSDSI home page is "JSDSI: A Java SPKI/SDSI
implementation", and technically, SPKI 2.0 is also SDSI 2.0 :)  But I
agree that name recognition is a good thing.  I'm not sure how to
accomplish this, though.

> And finally... In light of the inteded use of JSDSI, I definately feel
> that swaping to a LGPL would help people/companies feel more
> 'comfortable' in using the library.

Okay -- I'll just have to check with Ron Rivest et al that this is okay.

Thanks,
Sameer

>
> On Wed, 2004-02-11 at 00:38, Sameer Ajmani wrote:
>> Sean,
>>
>> Does your new code change any of the JSDSI core classes?  If not, we
>> could create a new JSDSI sub-package (jsdsi.whatever) with your
>> additional features.  I hesitate to change the name, only because
>> that may impact many existing users (and the project actually has
>> some name recognition).
>>
>> As for the license, changing it to LGPL is probably ok.  But we need
>> to retain the MIT copyright notice (separate from the license) on the
>> original classes, but not on your new classes.
>>
>> btw, be sure to check out my recent extensions to the Tag class
>> (support for full Tag intersection) and the new TagTest class in
>> jsdsi.test.
>>
>> Sameer
>>
>> > Hi guys,
>> >
>> > How are you both. I trust you are well and busy (and doing some fun
>> stuff).
>> >
>> > I myself have still been busy with SPKI related stuff based upong
>> JSDSI. In doing so I have created numerous utility classes to make it
>> easy to use in a J2EE application and for distributed proving and
>> searching of certificate chains - still much work to do to improve
>> and tidy it all up.
>> >
>> > And in a few weeks I may get some time to do just that and so have
>> a
>> proposal...
>> >
>> > I suggest amalgamating my stuff with the exisiting JSDSI codebase
>> and rebranding it as a new project to reflect the fact that SPKI is
>> now the more correct name. I agree to take on all this work and as
>> such am prepared to take on 'ownership' to manage its future work and
>> > corresponding web presence (with your guidance, naturally). I am
>> keen to really try to inject some interest it this cool library.
>> >
>> > Ideally I feel that the license needs to also be updated to an "OSI
>> Certified Open Source Software" one. My preference would be a LGPL
>> (http://www.opensource.org/licenses/lgpl-license.php), but how would
>> we/I go about that as regards to MIT (they may need to sign a
>> copyright disclaimer)?
>> >
>> > How do you guys feel about all this?
>> >
>> > Regards,
>> >
>> >
>> > Sean
>> >
>> > --
>> > Dr. Sean Radford, MBBS, MSc
>> > sra...@ae...
>>
>>
>> http://ajmani.net
>>
> --
> Dr. Sean Radford, MBBS, MSc
> sra...@ae...


http://ajmani.net


http://ajmani.net