more complex not "complex permissioning" in terms of what IBA is asking for (in the short-term). currently its an all or nothing setup on the server. and they want to have some variation in user rights against the media files. but, i agree this is not something that can be met in the short-term or with this initial piece of their funding. <br>
<br>also, if we are building out an API with some form of access control it will require some complexity. However, the complex permissioning that I think Lee was referring to was probably coming out of our discussion after looking at Fedora Repository (which is a digital archives repository middleware), and our review of SELinux as potential ways to make a secure API. Fedora repository has a fairly complex authorization model, and is somewhat of a standard in the digital repository field. It allows for the detailed logs, and very granular access control on all resources.<br>
<br>Also, just to clarify a bit, the API research that Lee and I were considering was not something we saw being completed by the end of this month :-)<br><br><div class="gmail_quote">On Thu, Mar 7, 2013 at 2:56 PM, Lee Azzarello <span dir="ltr"><<a href="mailto:lee@rockingtiger.com" target="_blank">lee@rockingtiger.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I didn't have any information about the budgets for individual<br>
clients. I thought InformaCam got a $400k grant from the Knight<br>
Foundation.<br>
<span class="HOEnZb"><font color="#888888"><br>
-lee<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Thu, Mar 7, 2013 at 2:48 PM, Hans-Christoph Steiner<br>
<<a href="mailto:hans@guardianproject.info">hans@guardianproject.info</a>> wrote:<br>
><br>
><br>
> On 03/06/2013 09:42 PM, barbra wrote:<br>
>> hi<br>
>><br>
>> some of what lee is proposing has come out of a discussion about how we can<br>
>> have a secure API and more complex authorizations. The API-focus is coming<br>
>> out of a few different needs:<br>
>><br>
>> 1. IBA wants to seperate the file storage system from the<br>
>> intake/verification system between the phone and server. An API way of<br>
>> communicating between functionality seems like the most elegant way to<br>
>> modularize (and would allow us to be more flexible on our server front-end<br>
>> as well as with phone interfaces as well), as this functionality is<br>
>> currently all intertwined in the existing system.<br>
>> Out of Lee and my discussion today, it was clear that secure API calls<br>
>> between these modular systems could be largely based on the work already<br>
>> done that you mentioned Nathan. The different servers could follow the<br>
>> same/similar verification process.<br>
>><br>
>> 2. IBA is requesting a fair amount of functionality outside of the scope of<br>
>> InformaCam<br>
>> (e.g., complex reporting, sharing with external clients, exporting<br>
>> submitted media, publishing on various outlets, etc.)<br>
>> Again, an API approach seemed like the best solution with the most gains.<br>
>> This we also considered OAuth as a good fit for. And it gives us a ready<br>
>> answer as these types of request will just keep coming...i.e., "yes, you<br>
>> can get that info through our API and use with x".<br>
>><br>
>> 3. IBA is requesting more complex permissioning for the server-side of<br>
>> users, as well as more complex evidence logs (and more complex logs are<br>
>> required in ISO standard for digital repos)<br>
>> This led us to review SELinux and Fedora Repository which both have complex<br>
>> permissions engines involved.<br>
><br>
> Has the IBA provided a scheme for this complex permissioning? If they need<br>
> something complex here, they should start by providing a detailed scheme of<br>
> what they want implemented. Also, wasn't the IBA funding only $25k? Or is<br>
> there more now? This would be way out of scope of a $25k project, on top of<br>
> all the other work that has been done.<br>
><br>
> .hc<br>
><br>
><br>
>> 4. General thoughts have been re-occurring on Guardian and IBA sides about<br>
>> having a "published" catalog of media derivatives (e.g., to media outlets,<br>
>> or for people who might be interested, etc.). This is something that<br>
>> actually Witness already does (though not managed completely with an IT<br>
>> system). Not a pressing needs, but something to consider as we refactor the<br>
>> architecture this time around.<br>
>><br>
>> I think Lee can speak to the need he sees with Math folks and the<br>
>> permission sets.<br>
>><br>
>> But I do think we needed to spend some time deciding how we would secure<br>
>> our "public-ish" and our internal system API(s), and go about building some<br>
>> permissions/authorization on the server-side.<br>
>><br>
>> -barbra<br>
>><br>
>><br>
>> On Wed, Mar 6, 2013 at 9:20 PM, Harlo Holmes <<a href="mailto:harlo.holmes@gmail.com">harlo.holmes@gmail.com</a>> wrote:<br>
>><br>
>>> I think this part of the project refers only to properly authenticating<br>
>>> IBA staff members as they interact with already-submitted media. (like, who<br>
>>> on the IBA team has access to view encrypted metadata, and keeping logs of<br>
>>> who viewed what and when.)<br>
>>><br>
>>> it should be outside the loop we established previously and has nothing to<br>
>>> do with the mobile client or its users. But Barbra can explain more...<br>
>>><br>
>>> Thanks,<br>
>>> Harlo<br>
>>> On Mar 6, 2013 9:03 PM, "Nathan of Guardian" <<a href="mailto:nathan@guardianproject.info">nathan@guardianproject.info</a>><br>
>>> wrote:<br>
>>><br>
>>>><br>
>>>><br>
>>>> Lee Azzarello <<a href="mailto:lee@rockingtiger.com">lee@rockingtiger.com</a>> wrote:<br>
>>>><br>
>>>>> Nathan,<br>
>>>>><br>
>>>>><br>
>>>>> Can you describe the level of detail for authorization of roles from<br>
>>>>> client to server? I don't think I understand the scope of this project<br>
>>>>> not the requirements to ensure a chain of custody in a court of law.<br>
>>>><br>
>>>> This is what the entire InformaCam IBA project has been doing for the<br>
>>>> last year. The Chain Of Custody issue is solved based on the signing and<br>
>>>> encryption Harlo has already implemented. You should be able to post<br>
>>>> informacam blobs into the public internet, as long as they have been signed<br>
>>>> by the submitters key and encrypted to the trusted parties key. We also<br>
>>>> have the file hash submission process that is again, already designed and<br>
>>>> implemented.<br>
>>>><br>
>>>> The only roles there were ever meant to be were 1) known or unknown<br>
>>>> person submitting a report from their device and 2) trusted party receiving<br>
>>>> report and being able to unpack and verify integrity of report blob.<br>
>>>><br>
>>>> I know we have added additional function to the server to allow searching<br>
>>>> and browsing of reports, but super complex roles and distributed computing<br>
>>>> authenticating mechanisms seems like we are way way out of any design goals<br>
>>>> I am familiar with.<br>
>>>><br>
>>>> Harlo, Bryan - can you provide some clarity here? Are we getting pushed<br>
>>>> in directions by the IBA that I am not aware of?<br>
>>>><br>
>>>> +n<br>
>>>> _______________________________________________<br>
>>>> Ssc-dev mailing list<br>
>>>><br>
>>>> Post: <a href="mailto:Ssc-dev@lists.mayfirst.org">Ssc-dev@lists.mayfirst.org</a><br>
>>>> List info: <a href="https://lists.mayfirst.org/mailman/listinfo/ssc-dev" target="_blank">https://lists.mayfirst.org/mailman/listinfo/ssc-dev</a><br>
>>>><br>
>>>> To Unsubscribe<br>
>>>> Send email to: <a href="mailto:Ssc-dev-unsubscribe@lists.mayfirst.org">Ssc-dev-unsubscribe@lists.mayfirst.org</a><br>
>>>> Or visit:<br>
>>>> <a href="https://lists.mayfirst.org/mailman/options/ssc-dev/harlo.holmes%40gmail.com" target="_blank">https://lists.mayfirst.org/mailman/options/ssc-dev/harlo.holmes%40gmail.com</a><br>
>>>><br>
>>>><br>
>>>> You are subscribed as: <a href="mailto:harlo.holmes@gmail.com">harlo.holmes@gmail.com</a><br>
>>>><br>
>>><br>
>>> _______________________________________________<br>
>>> Ssc-dev mailing list<br>
>>><br>
>>> Post: <a href="mailto:Ssc-dev@lists.mayfirst.org">Ssc-dev@lists.mayfirst.org</a><br>
>>> List info: <a href="https://lists.mayfirst.org/mailman/listinfo/ssc-dev" target="_blank">https://lists.mayfirst.org/mailman/listinfo/ssc-dev</a><br>
>>><br>
>>> To Unsubscribe<br>
>>> Send email to: <a href="mailto:Ssc-dev-unsubscribe@lists.mayfirst.org">Ssc-dev-unsubscribe@lists.mayfirst.org</a><br>
>>> Or visit:<br>
>>> <a href="https://lists.mayfirst.org/mailman/options/ssc-dev/blmack%40gmail.com" target="_blank">https://lists.mayfirst.org/mailman/options/ssc-dev/blmack%40gmail.com</a><br>
>>><br>
>>> You are subscribed as: <a href="mailto:blmack@gmail.com">blmack@gmail.com</a><br>
>>><br>
>>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Ssc-dev mailing list<br>
>><br>
>> Post: <a href="mailto:Ssc-dev@lists.mayfirst.org">Ssc-dev@lists.mayfirst.org</a><br>
>> List info: <a href="https://lists.mayfirst.org/mailman/listinfo/ssc-dev" target="_blank">https://lists.mayfirst.org/mailman/listinfo/ssc-dev</a><br>
>><br>
>> To Unsubscribe<br>
>> Send email to: <a href="mailto:Ssc-dev-unsubscribe@lists.mayfirst.org">Ssc-dev-unsubscribe@lists.mayfirst.org</a><br>
>> Or visit: <a href="https://lists.mayfirst.org/mailman/options/ssc-dev/hans%40guardianproject.info" target="_blank">https://lists.mayfirst.org/mailman/options/ssc-dev/hans%40guardianproject.info</a><br>
>><br>
>> You are subscribed as: <a href="mailto:hans@guardianproject.info">hans@guardianproject.info</a><br>
>><br>
> _______________________________________________<br>
> Ssc-dev mailing list<br>
><br>
> Post: <a href="mailto:Ssc-dev@lists.mayfirst.org">Ssc-dev@lists.mayfirst.org</a><br>
> List info: <a href="https://lists.mayfirst.org/mailman/listinfo/ssc-dev" target="_blank">https://lists.mayfirst.org/mailman/listinfo/ssc-dev</a><br>
><br>
> To Unsubscribe<br>
> Send email to: <a href="mailto:Ssc-dev-unsubscribe@lists.mayfirst.org">Ssc-dev-unsubscribe@lists.mayfirst.org</a><br>
</div></div><div class="im HOEnZb">> Or visit: <a href="https://lists.mayfirst.org/mailman/options/ssc-dev/lee%40guardianproject.info" target="_blank">https://lists.mayfirst.org/mailman/options/ssc-dev/lee%40guardianproject.info</a><br>
><br>
> You are subscribed as: <a href="mailto:lee@guardianproject.info">lee@guardianproject.info</a><br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Ssc-dev mailing list<br>
<br>
Post: <a href="mailto:Ssc-dev@lists.mayfirst.org">Ssc-dev@lists.mayfirst.org</a><br>
List info: <a href="https://lists.mayfirst.org/mailman/listinfo/ssc-dev" target="_blank">https://lists.mayfirst.org/mailman/listinfo/ssc-dev</a><br>
<br>
To Unsubscribe<br>
Send email to: <a href="mailto:Ssc-dev-unsubscribe@lists.mayfirst.org">Ssc-dev-unsubscribe@lists.mayfirst.org</a><br>
Or visit: <a href="https://lists.mayfirst.org/mailman/options/ssc-dev/blmack%40gmail.com" target="_blank">https://lists.mayfirst.org/mailman/options/ssc-dev/blmack%40gmail.com</a><br>
<br>
You are subscribed as: <a href="mailto:blmack@gmail.com">blmack@gmail.com</a><br>
</div></div></blockquote></div><br>