[OpenID-Specs-eKYC-IDA] Tokyo F2F : Meeting minutes

Naohiro Fujie naohiro.fujie at eidentity.jp
Wed Jan 29 08:38:49 UTC 2020

Hi all,

Here's meeting minutes of Tokyo F2F yesterday.
I'll explain in Today's regular call.

Date/Time: 28th Jan, 2020
Venue: NRI Otemachi Office
Organizer: Torsten, Naohiro
 - Anthony Nadalin / Microsoft
 - Taka Kawasaki / Authlete
 - Joseph Heenan / Authlete
 - Andrew Hindle / Hindle Consulting
 - Azusa Kikuchi / TRUSTDOCK
 - Masato Obata / KDDI
 - Kosuke Koiwai / KDDI
 - Yuichiro Ikeda / Decurret
 - Yoshio Watanabe / Idenpendent
 - Kimimasa Sato / Entrust Japan
 - Shibata Takehisa / NRI Secure
 - Nat Sakimura / NRI
 - Teruko Kaneshiro / NRI

 - OIDC4IDA overview / Torsten
 - AML Law in Japan / Azusa Kikuchi
 - OIDC4IDA Implementation on Authlete / Taka Kawasaki
 - Q&A and Discussion

 - OIDC4IDA overview / Torsten
   Torsten shows overview of OIDC4IDA and discussed how to utilize
this spec in Japan.
   KDDI which is one of the biggest mobile career in Japan, already
provides KYC API but current API does not provide user's attributes
itself, the API simply verify the attribute values which RP have match
the values which KDDI has. To apply OIDC4IDA on their API, they have
to change their policy to provide attribute itself.

 - AML Law in Japan / Azusa Kikuchi
   Azusa explain about situation around AML law in Japan. Financial
Service Agency in Japan defines various ways to verify identities
under AML law, but for service providers like crypt currency exchange
like to choose one or two ways in the provided ways because of user
coverage, cost efficiency and so on.

 - OIDC4IDA Implementation on Authlete / Taka Kawasaki
   Taka showed us short demo of current implementation of OIDC4IDA on
Authlete's service. That was quite cool!

 - Q&A and Discussion
   Mainly we discussed about three topics.
  1. How to represent two identity documents in current schema.
     In some case, RP want to verify identity using multiple identity
documents but in current JSON schema, it is difficult to present
multiple identity documents. We discovered that the current syntax can
represent the verification data Azusa needs, just a new verification
method is required. Azusa will fill a ticket suggesting at least this
new verification method.

  2. Language tags.
    Already Torsten have created ticket for this, we discussed on need
around multiple representation of value like Japanese Kanji, Kana for
not only claims but issuer name etc.
    And sometimes it would be better to have default or desired
language in request from RP.

  3. Name space
    We need to arrange name space on current JSON representation. Tony
will create ticket for this.



More information about the Openid-specs-ekyc-ida mailing list