<p><3 this discussion.</p>
<p>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.</p>

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