<p>&lt;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 &lt;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, &quot;Jonathan Lassoff&quot; &lt;<a href="mailto:jof@thejof.com">jof@thejof.com</a>&gt; 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 &lt;<a href="mailto:shannon@scatter.com">shannon@scatter.com</a>&gt; wrote:<br>
&gt; Well, that&#39;s just an index, right?  I want to be able to have a<br>
&gt; handle/name/whatever, and put a phone number, RFID key, keypad code, et<br>
&gt; cetera next to it; then when an auth event happens, I want to be able to<br>
&gt; take the auth code (a phone number, RFID match, keypad code) and look up the<br>
&gt; associated handle...<br>
<br>
I suppose. We&#39;re seeing eye-to-eye here, and using different words.<br>
That was the use case I was envisioning as well.<br>
<br>
&gt; Yes, exactly.  In theory, the chains of trust all lead back to Kelly... she<br>
&gt; says who the members are, and the members are allowed to give access to<br>
&gt; others down the tree; in practice, this just means that everyone should have<br>
&gt; a list of handles who have vouched for them; the system should follow those<br>
&gt; handles up the tree until one of them reaches Kelly or we run out of<br>
&gt; handles.<br>
<br>
Interesting way of describing it. I like it. How would we handle a<br>
reset, though? We&#39;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>
&gt; Yeah, I agree, this is an LDAP problem but OpenLDAP is terrible.  I thought<br>
&gt; I remembered hearing about an alternative free LDAP last year that was OK?<br>
&gt;  I don&#39;t remember what it was though.<br>
<br>
Beats me. I&#39;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>
&gt; The thing about OpenLDAP is, though, that there are lots of<br>
&gt; readily-available management tools (like Gosa) that we can just plug into<br>
&gt; 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&#39;d<br>
still have to write code to do our awesome-ness / vouching<br>
verification though. At that point, I don&#39;t think it would be *that*<br>
much more work to write a little data storage mechanism.<br>
I&#39;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>