[Openid-specs-mobile-profile] MODRNA WG call on Nov 13th 2018 preliminary minutes

[Brian Campbell]

Today and yesterday I opened PRs with proposed text to address the CIBA
issues that were assigned to me during the course of this call
https://bitbucket.org/openid/mobile/pull-requests/

On Wed, Nov 14, 2018 at 6:58 AM <philippe.clement at orange.com> wrote:

> Dear all,
> Please find below the preliminary minutes of our call pn Nov 13th 2018.
> In case of any error or misunderstanding, please let me know.
> *Roll Call*
> John Bradley
> Philippe Clement (Orange)
> Bjorn Hjelm (Verizon)
> Brian Campbell (Ping Identity)
> Dave
> Geoffrey Graham
> Joseph Heenan
> Petteri (Ubisecure)
> Charles Marais (Orange)
> *Adoption of the Agenda [Bjorn/John]*
> Agenda agreed
> *External Organizations*
> *IETF 103 [John]*
> No specific things addressing actual work in MODRNA. The Security guidance
> document is under discussions, subjects like protection of the token from
> injection replay are discussed.
> *GSMA [Siva]*
> Not addressed
> *Working Group Updates*
> *FAPI WG [Dave]*
> No particular activity to mention
> *Spec. Status*
> *CIBA  Core/MODRNA [Dave/Brian/Gonzalo/Axel]*
> Pull requests under progression
> *Discovery [John/Torsten]*
> All à have a look at *issue 87*
> <https://bitbucket.org/openid/mobile/issues/87/discovery-clean-up-draft-for-implementors>
> to access the specs.
> *Issue Tracker*
> *CIBA [Dave/Brian/Gonzalo/Axel]*
> .
> *#114: CIBA: slow_down*
> <https://bitbucket.org/openid/mobile/issues/114/ciba-slow_down>
> Consensus appears on not updating text but rely instead on device flow.
>
> *#112: CIBA: Require presence of jwks_uri conditionally*
> <https://bitbucket.org/openid/mobile/issues/112/ciba-require-presence-of-jwks_uri>
> Related to 72 as well.  Update needed to the text.
>
> *#115: CIBA: How about backchannel_notification_endpoint?*
> <https://bitbucket.org/openid/mobile/issues/115/ciba-how-about>
> Dave proposes the term backchannel_client_notification_endpoint ,
> consensus on the proposal
>
> *#116: CIBA: How about backchannel_notification_token?*
> <https://bitbucket.org/openid/mobile/issues/116/ciba-how-about>
> The term client_notification_token is kept
>
> *#117: CIBA: other request parameters when "request" is present*
> <https://bitbucket.org/openid/mobile/issues/117/ciba-other-request-parameters-when-request>
> Autentication request parameters MUST be inserted solely into the JWT
>
> *#109: Update CIBA examples*
> <https://bitbucket.org/openid/mobile/issues/109/update-ciba-examples>
> Feel free to comment or propose examples
>
> *#113: CIBA: the behavior when the "openid" scope value is not present*
> <https://bitbucket.org/openid/mobile/issues/113/ciba-the-behavior-when-the-openid-scope>
>
>    - Brian to update the text to mention why the behavior is unspecified
>    and it could be defined elsewhere
>
>
>
> *#111: CIBA: rt_hash*
> <https://bitbucket.org/openid/mobile/issues/111/ciba-rt_hash>
> Make public names would avoid collisions.
> Consensus to keep the public claim name.
>
> *#62: CIBA - Support for Spam Prevention code in Authentication Request*
> <https://bitbucket.org/openid/mobile/issues/62/ciba-support-for-spam-prevention-code-in>
> Bunch of conflicts. Needs to be resolved
>
>    - Petteri to work on it.
>    - All to re read the pull request.
>
>
> *#106: CIBA: Means to request claims to be embedded in the issued ID token*
> <https://bitbucket.org/openid/mobile/issues/106/ciba-means-to-request-claims-to-be>
> No obvious real Use Case. No specific to the MODRNA profile.
> Double check the text. (additional parameters ignored)
>
>    - Brian: to double check the text, and close it.
>
>
> *#103: CIBA: Means to require "acr" as "essential"*
> <https://bitbucket.org/openid/mobile/issues/103/ciba-means-to-require-acr-as-essential>
> Must the acr be included in the id_token ?
> What is “essential” ?
>
>    - Brian to update the text.
>
>
> *Discovery [John/Torsten]*
> *AOB*
> Meeting at same times nov 20th  for CIBA, And on 27th for usual call
>
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20181116/a35471e0/attachment.html>