[Ssc-dev] Authentication, Authorization and Architecture

Harlo Holmes harlo.holmes at gmail.com
Wed Mar 6 22:37:32 EST 2013 

<3 and :) and even ;)
On Mar 6, 2013 10:36 PM, "Harlo Holmes" <harlo.holmes at gmail.com> wrote:

> lol u guys just invite me to the damn hangout.
> On Mar 6, 2013 10:23 PM, "barbra" <blmack at gmail.com> wrote:
>
>> sure.
>>
>> On Wed, Mar 6, 2013 at 10:21 PM, Lee Azzarello <lee at rockingtiger.com>wrote:
>>
>>> 15 or 14?
>>> On Mar 6, 2013 10:00 PM, "barbra" <blmack at gmail.com> wrote:
>>>
>>>> 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/abc219e8/attachment.html>

More information about the Ssc-dev mailing list