i can do 16:00 gmt.<br><br>-barbra<br><br><div class="gmail_quote">On Wed, Mar 6, 2013 at 9:57 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"><p>I think sooner. Considering its 10 pm est and timezones, how is 16:00 gmt? </p><span class="HOEnZb"><font color="#888888">
<p>Lee</p></font></span><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On Mar 6, 2013 9:46 PM, "Harlo Holmes" <<a href="mailto:harlo.holmes@gmail.com" target="_blank">harlo.holmes@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">let's do another call tomorrow to go over these things. any time good for you all?</p>
<div class="gmail_quote">On Mar 6, 2013 9:42 PM, "barbra" <<a href="mailto:blmack@gmail.com" target="_blank">blmack@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
hi<br><br>some of what lee is proposing has come out of a discussion about how we can have a secure API and more complex authorizations. The API-focus is coming out of a few different needs:<br><br>1. IBA wants to seperate the file storage system from the intake/verification system between the phone and server. An API way of communicating between functionality seems like the most elegant way to modularize (and would allow us to be more flexible on our server front-end as well as with phone interfaces as well), as this functionality is currently all intertwined in the existing system. <br>
Out of Lee and my discussion today, it was clear that secure API calls between these modular systems could be largely based on the work already done that you mentioned Nathan. The different servers could follow the same/similar verification process.<br>
<br>2. IBA is requesting a fair amount of functionality outside of the scope of InformaCam<br>
(e.g., complex reporting, sharing with external clients, exporting submitted media, publishing on various outlets, etc.)<br>Again, an API approach seemed like the best solution with the most gains. This we also considered OAuth as a good fit for. And it gives us a ready answer as these types of request will just keep coming...i.e., "yes, you 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 users, as well as more complex evidence logs (and more complex logs are required in ISO standard for digital repos)<br>This led us to review SELinux and Fedora Repository which both have complex permissions engines involved.<br>
<br>4. General thoughts have been re-occurring on Guardian and IBA sides about having a "published" catalog of media derivatives (e.g., to media outlets, or for people who might be interested, etc.). This is something that actually Witness already does (though not managed completely with an IT system). Not a pressing needs, but something to consider as we refactor the architecture this time around.<br>
<br>I think Lee can speak to the need he sees with Math folks and the permission sets. <br><br>But I do think we needed to spend some time deciding how we would secure our "public-ish" and our internal system API(s), and go about building some permissions/authorization on the server-side.<br>
<br>-barbra<br>
<br><br><div class="gmail_quote">On Wed, Mar 6, 2013 at 9:20 PM, Harlo Holmes <span dir="ltr"><<a href="mailto:harlo.holmes@gmail.com" target="_blank">harlo.holmes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">I think this part of the project refers only to properly authenticating IBA staff members as they interact with already-submitted media. (like, who on the IBA team has access to view encrypted metadata, and keeping logs of who viewed what and when.) </p>
<p dir="ltr">it should be outside the loop we established previously and has nothing to do with the mobile client or its users. But Barbra can explain more...</p>
<p dir="ltr">Thanks,<br>
Harlo</p>
<div class="gmail_quote"><div><div>On Mar 6, 2013 9:03 PM, "Nathan of Guardian" <<a href="mailto:nathan@guardianproject.info" target="_blank">nathan@guardianproject.info</a>> wrote:<br type="attribution">
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
<br>
<br>
Lee Azzarello <<a href="mailto:lee@rockingtiger.com" target="_blank">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 last year. The Chain Of Custody issue is solved based on the signing and encryption Harlo has already implemented. You should be able to post informacam blobs into the public internet, as long as they have been signed by the submitters key and encrypted to the trusted parties key. We also have the file hash submission process that is again, already designed and implemented.<br>
<br>
The only roles there were ever meant to be were 1) known or unknown person submitting a report from their device and 2) trusted party receiving 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 and browsing of reports, but super complex roles and distributed computing authenticating mechanisms seems like we are way way out of any design goals I am familiar with.<br>
<br>
Harlo, Bryan - can you provide some clarity here? Are we getting pushed in directions by the IBA that I am not aware of?<br>
<br>
+n<br></div></div><div>
_______________________________________________<br>
Ssc-dev mailing list<br>
<br>
Post: <a href="mailto:Ssc-dev@lists.mayfirst.org" target="_blank">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" target="_blank">Ssc-dev-unsubscribe@lists.mayfirst.org</a><br></div>
Or visit: <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><div><br>
<br>
You are subscribed as: <a href="mailto:harlo.holmes@gmail.com" target="_blank">harlo.holmes@gmail.com</a><br>
</div></blockquote></div>
<br>_______________________________________________<br>
Ssc-dev mailing list<br>
<br>
Post: <a href="mailto:Ssc-dev@lists.mayfirst.org" target="_blank">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" target="_blank">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" target="_blank">blmack@gmail.com</a><br>
<br></blockquote></div><br>
</blockquote></div>
</blockquote></div>
</div></div></blockquote></div><br>