[Ssc-dev] Authentication, Authorization and Architecture

Thu Mar 7 14:56:07 EST 2013

I didn't have any information about the budgets for individual
clients. I thought InformaCam got a $400k grant from the Knight
Foundation.

-lee

On Thu, Mar 7, 2013 at 2:48 PM, Hans-Christoph Steiner
<hans at guardianproject.info> wrote:
>
>
> On 03/06/2013 09:42 PM, barbra wrote:
>> hi
>>
>> 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:
>>
>> 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.
>> 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.
>>
>> 2. IBA is requesting a fair amount of functionality outside of the scope of
>> InformaCam
>> (e.g., complex reporting, sharing with external clients, exporting
>> submitted media, publishing on various outlets, etc.)
>> 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".
>>
>> 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)
>> This led us to review SELinux and Fedora Repository which both have complex
>> permissions engines involved.
>
> Has the IBA provided a scheme for this complex permissioning?  If they need
> something complex here, they should start by providing a detailed scheme of
> what they want implemented.  Also, wasn't the IBA funding only $25k? Or is
> there more now?   This would be way out of scope of a $25k project, on top of
> all the other work that has been done.
>
> .hc
>
>
>> 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.
>>
>> I think Lee can speak to the need he sees with Math folks and the
>> permission sets.
>>
>> 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.
>>
>> -barbra
>>
>>
>> On Wed, Mar 6, 2013 at 9:20 PM, Harlo Holmes <harlo.holmes at gmail.com> wrote:
>>
>>> 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.)
>>>
>>> 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...
>>>
>>> Thanks,
>>> Harlo
>>> On Mar 6, 2013 9:03 PM, "Nathan of Guardian" <nathan at guardianproject.info>
>>> wrote:
>>>
>>>>
>>>>
>>>> Lee Azzarello <lee at rockingtiger.com> wrote:
>>>>
>>>>> Nathan,
>>>>>
>>>>>
>>>>> Can you describe the level of detail for authorization of roles from
>>>>> client to server? I don't think I understand the scope of this project
>>>>> not the requirements to ensure a chain of custody in a court of law.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> Harlo, Bryan - can you provide some clarity here? Are we getting pushed
>>>> in directions by the IBA that I am not aware of?
>>>>
>>>> +n
>>>> _______________________________________________
>>>> Ssc-dev mailing list
>>>>
>>>> Post: Ssc-dev at lists.mayfirst.org
>>>> List info: https://lists.mayfirst.org/mailman/listinfo/ssc-dev
>>>>
>>>> To Unsubscribe
>>>>         Send email to:  Ssc-dev-unsubscribe at lists.mayfirst.org
>>>>         Or visit:
>>>> https://lists.mayfirst.org/mailman/options/ssc-dev/harlo.holmes%40gmail.com
>>>>
>>>>
>>>> You are subscribed as: harlo.holmes at gmail.com
>>>>
>>>
>>> _______________________________________________
>>> Ssc-dev mailing list
>>>
>>> Post: Ssc-dev at lists.mayfirst.org
>>> List info: https://lists.mayfirst.org/mailman/listinfo/ssc-dev
>>>
>>> To Unsubscribe
>>>         Send email to:  Ssc-dev-unsubscribe at lists.mayfirst.org
>>>         Or visit:
>>> https://lists.mayfirst.org/mailman/options/ssc-dev/blmack%40gmail.com
>>>
>>> You are subscribed as: blmack at gmail.com
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Ssc-dev mailing list
>>
>> Post: Ssc-dev at lists.mayfirst.org
>> List info: https://lists.mayfirst.org/mailman/listinfo/ssc-dev
>>
>> To Unsubscribe
>>         Send email to:  Ssc-dev-unsubscribe at lists.mayfirst.org
>>         Or visit: https://lists.mayfirst.org/mailman/options/ssc-dev/hans%40guardianproject.info
>>
>> You are subscribed as: hans at guardianproject.info
>>
> _______________________________________________
> Ssc-dev mailing list
>
> Post: Ssc-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/ssc-dev
>
> To Unsubscribe
>         Send email to:  Ssc-dev-unsubscribe at lists.mayfirst.org
>         Or visit: https://lists.mayfirst.org/mailman/options/ssc-dev/lee%40guardianproject.info
>
> You are subscribed as: lee at guardianproject.info