[Ssc-dev] Authentication, Authorization and Architecture

Wed Mar 6 22:00:25 EST 2013

i can do 16:00 gmt.

-barbra

On Wed, Mar 6, 2013 at 9:57 PM, Lee Azzarello <lee at rockingtiger.com> wrote:

> I think sooner.  Considering its 10 pm est and timezones, how is 16:00
> gmt?
>
> Lee
> On Mar 6, 2013 9:46 PM, "Harlo Holmes" <harlo.holmes at gmail.com> wrote:
>
>> let's do another call tomorrow to go over these things. any time good for
>> you all?
>> On Mar 6, 2013 9:42 PM, "barbra" <blmack at gmail.com> 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.
>>>
>>> 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
>>>>
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/ssc-dev/attachments/20130306/67850f2f/attachment.html>