<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 9, 2015 at 6:43 PM, Corinne Krych <span dir="ltr"><<a href="mailto:corinnekrych@gmail.com" target="_blank">corinnekrych@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>As I already mentioned it, we can move those configurations into social repo. Let me create a JIRA on iOS to decouple oauth2 vs social repo (social being dependant on oauth2). Sth we discussed and agreed upon with abstractj (I can't find the thread though, it might have being during security meeting).<br></div></div></blockquote><div><br></div><div><br></div><div>I recall that discussion, and since both sides here have valid arguments, let's do that:</div><div>- authz (on Android) and -oauth2 on iOS/Windows/Cordova implement the raw, API</div><div> -social: contains some of these convenient configurations, to make users life easier<br></div><div><br></div><div>However I do NOT think that means we need to implement a ton of different social adapters. It's more something for our users convenience and if users want to contribute configurations for different services, that's the way to go.</div><div><br></div><div>This means we can still focus on a clear/clean/raw OAuth2 impl., while having configurations for some 3rd parties.</div><div><br></div><div>-Matthias</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div><div>A nice entry point to demo OAuth2 is to use external providers as we did for shoot demo app.</div><div><br></div></div><div>Another point i don't understand what so bad into renaming android-authz to android-oauth2?</div><div><br></div><div>++</div><span class="HOEnZb"><font color="#888888"><div>Corinne</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 9 March 2015 at 17:58, Summers Pittman <span dir="ltr"><<a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span>
<div>On 03/09/2015 12:50 PM, Matthias
Wessendorf wrote:<br>
</div>
</span><span><blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Mar 9, 2015 at 5:34 PM,
Summers Pittman <span dir="ltr"><<a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 03/09/2015 12:15 PM, Erik Jan de Wit wrote:<br>
>> Because Facebook and Google are well known for
not making arbitrary changes to public apis and
configurations.<br>
>><br>
>> More importantly as an Open Source project
hitching our code to the configuration of a third party
proprietary system is terrifyingly bad karma. Push is
an exception ONLY because there isn't an equvalent open
solution which has the same reach to devices.<br>
> It’s just some configuration, what point does
oauth2 have when it doesn’t work with Facebook and
Google.<br>
</span>/me looks at the shoot and share demo, and the
gdrive demo.<br>
Looks like it does work with FB and Google. Did you have
a specific<br>
example in mind?<br>
<span>> The whole point of our libs is to make
it easy for developers to do these complex things adding
this config makes it super easy. I don’t see:
”Terrifyingly bad karma” a good reason not to do this.<br>
</span>Because it is hitching our open source project to
the largess of<br>
proprietary service vendors. If they change THEIR
configuration and OUR<br>
libraries break WE look like the bad guys not them for
starters.<br>
</blockquote>
<div><br>
</div>
<div>That happened with push (Google's documentation, not
the APIs) in the past, and may happen again. We reacted
pretty quick on that one, which is what matters. If we
would not react, we would look bad.</div>
</div>
</div>
</div>
</blockquote></span>
If we don't hard code their configuration into the API then when
they change it we don't look bad. WIN-WIN<span><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Perhaps we can add a statement that the code executes
against a 3rd party service, that we don't own. That can
even happen with differen Keycloak versions. However,
usually actual API changes from the big players are
usually announced, and it's usually comes with a little
bit of time to react.</div>
</div>
</div>
</div>
</blockquote></span>
Back to who is responsible for monitoring the changes from these
guys?<span><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Additionally the only direction this can go is toward
scope creep. Once<br>
we have Facebook and Google nothing is stopping
(rhetorically) from<br>
adding Facebook, Yahoo, VK, Microsoft, etc. Now we are
maintaining 5x<br>
as many configurations as we were before. </blockquote>
<div><br>
</div>
<div>I'd not add more, out of the blue. But if there is
demand (from which ever direction), it's time to react on
that demand, but not before</div>
</div>
</div>
</div>
</blockquote></span>
Fair enough. We have demand from VK already so why not add that on
in right now?<div><div><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Who is
going to monitor those<br>
APIs and make sure they don't break/get deprecated? Do we
cut a release<br>
because one auth provider changed their config?<br>
<br>
Of course we don't because that is the responsibility of
the app<br>
developer to make sure their configuration for the
services they consume<br>
is up to date. It is not and should not be our
responsibility.<br>
<br>
I freely admit it is nice and it is convenient but it does
not belong in<br>
the project.<br>
</blockquote>
<div><br>
</div>
<div>Instead, we don't offer any concrete impls for Google
or Facebook? Or use a complicated and generic API, which
may work, or not? </div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
<br>
><br>
><br>
> _______________________________________________<br>
> aerogear-dev mailing list<br>
> <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
<br>
<br>
</span><span>--<br>
Summers Pittman<br>
>>Phone:<a href="tel:404%20941%204698" value="+14049414698" target="_blank">404 941 4698</a><br>
>>Java is my crack.<br>
<br>
</span>
<div>
<div>_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div>Matthias Wessendorf <br>
<br>
blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a></div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
aerogear-dev mailing list
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></pre>
</blockquote>
<br>
<br>
<pre cols="72">--
Summers Pittman
>>Phone:<a href="tel:404%20941%204698" value="+14049414698" target="_blank">404 941 4698</a>
>>Java is my crack.
</pre>
</div></div></div>
<br>_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a></div>
</div></div>