[Code] Discussion continuation of AppAuth-JS PR #67

[Chinthaka Senanayaka]

Hi,

AppAuth-JS PR #67 <https://github.com/openid/AppAuth-JS/pull/67> was closed
with some comments and I think the code is still useful for the community.
And we may take initiative for the extension library development in the
future for non core OIDC (OpenID Connect) functionalities.

We can contribute to the AppAuth-JS to have functionality aligning the OIDC
spec.

I have some questions to clarify.

Q1. As of core OIDC spec, we can add userInfo route
<http://openid.net/specs/openid-connect-core-1_0.html#UserInfo> the AppAuth-JS
library <https://github.com/openid/AppAuth-JS>. So, I have given on #67 PR
an optional method to the library which is beneficial for you. Are you good
with this? If not please inform the alternative way of you architectural
roadmap that you already have for the OIDC, may be I can contribute that.
But I still think the implementation of userInfo route code is useful. Then
I can send a separate PR only with the changes for userInfo.

Moreover, As of PR #67 <https://github.com/openid/AppAuth-JS/pull/67> seems
you want to follow Oauth2, but this AppAuth-JS is about OpenID Connect I
think and it is listed under https://github.com/openid/* OpenID Foundation.
So, userInfo functionality should lie under the AppAuth-JS library. So, I
see contradiction here.

Q2. What is your architectural approach for OIDC logout (end session
route)? As of draft OIDC spec, there should be a logout implementation
<http://openid.net/specs/openid-connect-session-1_0.html#RPLogout>. In PR
#67 <https://github.com/openid/AppAuth-JS/pull/67> I have added OIDC
logout, since it is not in the core OIDC spec, we can move it to the
extension library as well. Or else, since it is in OIDC spec draft, I can
send it as a separate PR. So, what is the future architectural move for
this draft OIDC end session spec?

Q3. PKCE for web clients: As of the AppAuth-JS PR #28
<https://github.com/openid/AppAuth-JS/issues/28> we can move with
authorization request field extras. But does that cover enough scope of Oauth2
PKCE spec <https://tools.ietf.org/html/rfc7636#section-1> by the OpenID
Connect Foundation's AppAuth-JS library? If an Appauth-JS user app should
generate PKCE verifier and challenge, PKCE spec is not fully covered under
this library, it flows to the user's code and it can be duplicated. What I
can suggest is, we can give the verifier and challenge generated and added
to the token request only if user code does not send those fields via
extras. What do you think on this?

Q4. I assume WebCrypto means window.crypto here in Javascript (it is not
explained in the PR #67 properly because webcrypto-npm
<https://www.npmjs.com/package/webcrypto>, window.crypto and webcrypto
<https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API> exist). I
saw node_support but using window.crypto will not work with NodeJs. I saw
AppAuth-JS has used a workaround in crypto_utils.ts
<https://github.com/openid/AppAuth-JS/blob/master/src/crypto_utils.ts> line
29. For node support, it is like reinventing the wheel by not using an
existing crypto library. But still I can send you a separate PR, if you
clearly explain the architectural requirement because this is not related
to any concerns with OIDC spec or Oauth2 spec.

If there are any unclear points made by me, let me know.

-- 
Chinthaka Senanayaka
Mobile: +94 77 11 99 603
LinkedIn <https://lk.linkedin.com/in/csenanayaka>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-code/attachments/20180810/4139f8a8/attachment.html>