Agenda

• London F2F Meeting Agenda
• Review of tickets and issues

  • https://bitbucket.org/openid/ekyc-ida/issues/1094/how-to-treat-unknown-identifiers-in-claims (Marcos)
  • https://bitbucket.org/openid/ekyc-ida/pull-requests/5
  • https://bitbucket.org/openid/ekyc-ida/pull-requests/6
  • https://bitbucket.org/openid/ekyc-ida/pull-requests/7
  • https://bitbucket.org/openid/ekyc-ida/pull-requests/8
  • https://bitbucket.org/openid/ekyc-ida/issues/1153/request-syntax-complexity (Daniel F)
  • https://bitbucket.org/openid/ekyc-ida/issues/1142/drop-claims-short-cut
  • https://bitbucket.org/openid/ekyc-ida/issues/1156/maintain-publish-json-schema-in-single

Attendees:

• Nat Sakimura
• Torsten Lodderstedt
• Mark Haine
• Kosuke Koiwai
• Jan Kelin
• Dima Postnikov
• Joseph Heenan
• Marcos Sanz
• Stuart Low
• Brian Campbell
• Achim Schlosser
• Rob Otto
• Azusa Kikuchi
• Wesley Dunnington
• Alberto Pulido
• Maciej Machulak
• Bjorn Hjelm
• Daniel Fett

London F2F Meeting Agenda

• Proposed Agenda

  • Introduction to eKYC and Identity Assurance
  • Suggestion to add identifying jurisdictions that have experience of eKYC but without a technical standard as a discussion point
  • Mark to investigate Akamai can support dial in well

Issues and pull requests

• Issue #1094 how-to-treat-unknown-identifiers-in-claims

  • option to provide available claims
  • option to reject the request
  • Suggestion is to return an specific error
  • this is relating to evidence type rather than a claim relating to an identity
  • Seems reasonable to Torsten, Mark and Rob

• Pull request 5

  • Marcos and Vladimir have approved
  • As there are no objections Torsten has merged

• Issue #1156

  • Torsten raised question regarding schema - it is in two places - in a schema in the repo and also in the spec and there were some differences
  • Suggestion is that the schema is separated from the spec an dthe JSON schema separately
  • Rob observed that it would be impractical to keep inside the spec document

• Issue #1162

  • what do people think about creating a schema for the request?
  • Will be raised to Takahiko Kawasaki and Vladimir Dzhuvinov one other as they have on-going implementations

• Pull request 6

  • Marcos not available - deferred

• Pull request 7

  • Adding reference to Japanese law on the matter - Kosuke Koiwai just started working on this

• Pull request 8

  • removal of all but necessary "required" declarations
  • the feeling is there are too many
  • Should in future only use "required" is when it is obviously always necessary
  • This needs a reviewer - Torsten will send another post to the list

• Issue #1153 - request syntax complexity

  • Daniel Fett spoke on this topic
  • There are several different symantics in teh request and that it is hard to implement
  • It would be good to put more work into the syntax to make implementation easier
  • There is not a proposed solution yet
  • There are a few ideas, key-value-pair or separated into [filtering the response, essential claim, purpose]
  • It may also be useful to provide for conditional
  • Torsten asked that this is discussed at the F2F in London
  • Stuart Low asked whether a JSON schema be defined
  • The current philosophy is to use the same format for request and response
  • Stuart suggests looking at the OpenAPI 3 spec as it may be useful

• Issue #1077 - List other laws or trust services

  • Mark followed up with other attendees who took actions to identify these in their locality
  • Dima and MarcusA both replied that they have started work on this but do not have anything to share at present
  • Mark mentiohned that India has an eKYC system that has been running for a number of years so some representation fromn tere would be useful