Subject: Re: [OAUTH-WG] OAuth 2.0 for Native Apps: open source client libraries

From: Andy Zmolek <[email-masked]>
Date: Fri, 1 Apr 2016 18:39:39 -0700

> Any plan to bring the libraries to more ?young? languages like Swift in
iOS and Kotlin in Android?

Are you volunteering?

---

From: John Bradley <[email-masked]>
Date: Sat, 2 Apr 2016 09:44:48 -0300

The current iOS version works just fine with apps written in Swift.

I don’t know that there is a compelling reason to support two code bases on the same platform as long as the SDK supports all the development tools.

Other than as an example, do you have a reason for needing it in Swift?

At the moment the focus is more on expanding the functionality.

Adding options for creating and validating JWT/id_tokens,  JWE encryption support ,  Token binding for refresh tokens that can use the TPM for security,  Application Configuration via a EMM (AppConfig) ,  Alignment with the the GSMA Mobile Connect SDK so that developers don’t wind up needing one SDK for Azure and another to support the Mobile Network Operator openID service.

Let us know what directions are important to you.

Regards
John B.

> On Apr 1, 2016, at 10:39 PM, Andy Zmolek <[email-masked]> wrote:
> 
> > Any plan to bring the libraries to more ?young? languages like Swift in iOS and Kotlin in Android?
> 
> Are you volunteering?
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 4 Apr 2016 12:35:27 -0700

Thanks for providing the open source libraries. I tested them (on
Android), and it works nicely.

Best regards
Ulrich

---

From: Eduardo Gueiros <[email-masked]>
Date: Mon, 11 Apr 2016 15:14:08 -0600

No, no especial need at this time. It was more out of curiosity, you guys
did a great work...and quick too!

I mean, It's just nice for a new project in Swift to be able to work with
Swift libraries instead of having to mock with bridging files and @objc
annotations. But again, not a strong reason at this time.

I did find https://github.com/p2/OAuth2 which is Swift and adheres to the
Best Practices document by using SFSafariViewController for OAuth, so since
someone else is working on it I will not be volunteering to re-invent the
wheel :)

Keep up the good work!

On Sat, Apr 2, 2016 at 6:44 AM, John Bradley <[email-masked]> wrote:

> I don’t know that there is a compelling reason to support two code bases
> on the same platform as long as the SDK supports all the development tools.
>
> Adding options for creating and validating JWT/id_tokens,  JWE encryption
> support ,  Token binding for refresh tokens that can use the TPM for
> security,  Application Configuration via a EMM (AppConfig) ,  Alignment
> with the the GSMA Mobile Connect SDK so that developers don’t wind up
> needing one SDK for Azure and another to support the Mobile Network
> Operator openID service.
>

-- 
-- 
*Eduardo Gueiros*
*Director, Mobile B.U.* |  Jive Communications, Inc.
jive.com  |  [email-masked] <[email-masked]>*
<http://www.facebook.com/jive.communications.inc>
<http://www.twitter.com/getjive> <http://goplus.us/jive>
<http://www.youtube.com/jivetalks>
<http://www.linkedin.com/company/jive-communications-inc>

---

From: William Denniss <[email-masked]>
Date: Mon, 11 Apr 2016 17:53:21 -0700

> did a great work...and quick too!

Thanks :-)

> annotations. But again, not a strong reason at this time.

One thing we need to do is publish an example in Swift showing the
integration, and test it all. I've created
https://github.com/openid/AppAuth-iOS/issues/19 to track that, feel free to
subscribe.

I'm hoping we can create a seamless experience for Swift developers, so
that (in so much as possible) it won't matter to them what language the
underlying library is written in. I don't see any value in the extra work
of porting the library if we can get it working well in Swift. But we do
need to verify that, add Swift it to our testing, and get out a sample.

> someone else is working on it I will not be volunteering to re-invent the

p2/OAuth2 doesn't appear to be following the draft best practice
<https://tools.ietf.org/html/draft-ietf-oauth-native-apps> fully, it
doesn't send PKCE, and is currently recommending using WebView to sign-in
to Google on iOS (filed a bug <https://github.com/p2/OAuth2/issues/102> for
the latter).

Keep up the good work!

Thanks for the feedback!