[Noisebridge-discuss] Access control & Safety, both personal and general space.

[rachel lyra hospodar]

<3 this discussion.

I want to point out that decentralization and mistrust of power in the
hands of individuals reccomends against putting control in the hands of
treasurer, an individual. I <3 Kelly but she may want to do something else
with her time eventually, and be replaced with someone who turns out to be
an evil despot.

R.

mediumreality.com
On Feb 8, 2012 4:10 PM, "Jonathan Lassoff" <jof at thejof.com> wrote:

> On Wed, Feb 8, 2012 at 3:08 PM, Shannon Lee <shannon at scatter.com> wrote:
> > Well, that's just an index, right?  I want to be able to have a
> > handle/name/whatever, and put a phone number, RFID key, keypad code, et
> > cetera next to it; then when an auth event happens, I want to be able to
> > take the auth code (a phone number, RFID match, keypad code) and look up
> the
> > associated handle...
>
> I suppose. We're seeing eye-to-eye here, and using different words.
> That was the use case I was envisioning as well.
>
> > Yes, exactly.  In theory, the chains of trust all lead back to Kelly...
> she
> > says who the members are, and the members are allowed to give access to
> > others down the tree; in practice, this just means that everyone should
> have
> > a list of handles who have vouched for them; the system should follow
> those
> > handles up the tree until one of them reaches Kelly or we run out of
> > handles.
>
> Interesting way of describing it. I like it. How would we handle a
> reset, though? We'd need some way to prune the pointer to the vouching
> node(s).
> It would be nice if we could continue to cache access token info along
> with the handle, and not have to re-enter it every time.
>
> If we allow multiple vouching nodes, searching the tree to verify a
> chain of awesome-ness back to Kelly can quickly turn into a hard
> problem though. If one vouching is as good as three, I say we just
> store one and keep the additional stuff as metadata.
>
> > Yeah, I agree, this is an LDAP problem but OpenLDAP is terrible.  I
> thought
> > I remembered hearing about an alternative free LDAP last year that was
> OK?
> >  I don't remember what it was though.
>
> Beats me. I've been futzing some with FreeIPA lately, and have found
> it to be generally useful for getting LDAP up without much work.
>
> > The thing about OpenLDAP is, though, that there are lots of
> > readily-available management tools (like Gosa) that we can just plug into
> > the problem, and not have to write any of this ourselves.
>
> I think that OpenLDAP would just be a storage mechanism for us. We'd
> still have to write code to do our awesome-ness / vouching
> verification though. At that point, I don't think it would be *that*
> much more work to write a little data storage mechanism.
> I'm thinking like JSON blobs in a Redis or flat text file.
>
> Cheers,
> jof
> _______________________________________________
> Noisebridge-discuss mailing list
> Noisebridge-discuss at lists.noisebridge.net
> https://www.noisebridge.net/mailman/listinfo/noisebridge-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.noisebridge.net/pipermail/noisebridge-discuss/attachments/20120209/23e13339/attachment-0003.html>