<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">&lt;<a href="mailto:corinnekrych@gmail.com" target="_blank">corinnekrych@gmail.com</a>&gt;</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&#39;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&#39;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&#39;s more something for our users convenience and if users want to contribute configurations for different services, that&#39;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&#39;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">&lt;<a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>&gt;</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">&lt;<a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>&gt;</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>
                &gt;&gt; Because Facebook and Google are well known for
                not making arbitrary changes to public apis and
                configurations.<br>
                &gt;&gt;<br>
                &gt;&gt; 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&#39;t an equvalent open
                solution which has the same reach to devices.<br>
                &gt; 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>&gt; 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&#39;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&#39;t hard code their configuration into the API then when
    they change it we don&#39;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&#39;t own. That can
              even happen with differen Keycloak versions. However,
              usually actual API changes from the big players are
              usually announced, and it&#39;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&#39;d not add more, out of the blue. But if there is
              demand (from which ever direction), it&#39;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&#39;t break/get deprecated?  Do we
              cut a release<br>
              because one auth provider changed their config?<br>
              <br>
              Of course we don&#39;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&#39;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>
                &gt;<br>
                &gt;<br>
                &gt; _______________________________________________<br>
                &gt; aerogear-dev mailing list<br>
                &gt; <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
                &gt; <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>
                &gt;&gt;Phone:<a href="tel:404%20941%204698" value="+14049414698" target="_blank">404 941 4698</a><br>
                &gt;&gt;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
&gt;&gt;Phone:<a href="tel:404%20941%204698" value="+14049414698" target="_blank">404 941 4698</a>
&gt;&gt;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>